Tech Is Hard

Credibility = Talent x Years of experience + Proven hardcore accomplishment

What I Can Do

Show you ways to use your technology that are more robust, transparent and continually simplify your future development.  I can imagine what you’re thinking: “Sure.  He’s going to find new___ in not only the OTS technologies we’ve been using for years, but also our own system architecture.  Right.”

The plain fact is that’s what I’ve achieved everywhere that I’ve been for any length of time.  I stress “everywhere”.  With languages I hadn’t previously used and had been in use for years.  Sometimes in the first few days.  I see things that others don’t as a result of my own obsession with patterns and language combined with 30 years of programming.  I’ve simply seen more IT problems than most people in the field and have a bigger perspective on the possible solutions.

Things still boil down mostly to fundamental principles taught in structured analysis and design.  Object oriented programming, for instance, is just a mechanism to enforce these principles, in my opinion; I achieved encapsulation and polymorphism with simplistic languages like assembler and C, through strict interfaces, documented contracts and function pointers.

New technologies certainly evolve the way I look at those fundamentals, but that’s a process of constantly growing one’s mental model, just like we should never be hesitant to refactor new knowledge into our core systems — rather than slapping special logic into all of our applications.

I love programming and thinking about how the pieces fit together, ever since I coded my first lunar lander on a TRS-80. I love very hard thinking that results in simple implementation. I love oscillating my thinking between specific functionality and high level system design. I was trained on the fundamentals and I had some excellent programming mentors. I’ve worked with a few incredibly talented and intelligent individuals in my 25 plus-year career.

Frankly, during that time I worked 7 days a week and nights, more often than not. Considering all the C and assembler code I’ve read and written, it could be in the billions of lines. So this means I’m not better than anyone else, I’ve just seen a lot more problems and solutions than most. I’ve lived with my systems for years and that experience makes me see the “badness” in certain proposals more quickly.

I’m an iconoclast by nature. If something is an established way of thinking or being or doing, I mentally rebel. To me, the obvious answer to a problem is often not the best answer and we should question it.

I’ve offended some people during that time and I were better at communicating, but it’s frustrating to swim upstream all the time. I’m at least confident that what was accomplished technically is still a source of income and pride to the organizations I’ve served.

Design should be done in the abstract, with implementation in the specific. I’m constantly checking my mental model for satisfying the requirements of the moment, but spend most of my time thinking at least one level up from them.

Agile, at least as I first saw it, was good. I don’t know what it is anymore. Pair programming IS good, or even 3-way programming when simultaneously making changes to multiple layers. The concept of specific design patterns has lost its utility. “Look everyone, this is the ‘deja-vu redundancy pattern’.”

Processes and labelled patterns cannot replace people who can think about hard things at many levels. They can’t fill a void if no one understands what really contributes to a long living system that adapts well to future needs and lowers costs and frustration.

I’m not that interested in popular frameworks, enterprise buses or the latest implementation as much as I’m interested in the latest application of a concept. New technology is awesome when it’s really new.

Anything really new requires a shift in thought, first. In my world, you have to be comfortable with the science to do that, even if you don’t know the terminology, because it requires transcending the technology. And the science hasn’t changed.

What’s changed is the direct result of the technology explosion and its subsequent demand for workers. The software development market has fragmented and I think the supply chain hasn’t really figured out how to differentiate the product to satisfy the market segments. It’s all still subject to basic principles, but a lot of the segments simply don’t have the same reliability, efficiency or maintenance requirements, so it may be cost effective for them to stray and use short term thinking.

I think we have trouble communicating now because we’re still all in one room, speaking different languages. We can’t agree on labels ourselves, so how can we give “truth in labeling” to our customers?

If I think an issue is important and you don’t, I think you should listen, in a while it will probably be obvious.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: