Unknowns

An all too common problem in software is that you now have to do some work, but for you, it is a brand new task. You've never done anything like this before.

So, right out of the gate, there are a lot of unknowns.

One way to handle this is to dive in directly. Just go straight into the things you have to do and thrash your way through the problems one by one.

In the midst of doing that though, you’ll probably have to make a lot of decisions. Setup, configuration, conventions, organization, etc. But more often than not the correct decision is not the most intuitive one. They are often quite different.

If you’ve been around for a long long time, your intuition has probably been honed by plenty of similar experiences, but if you are relatively new to this type of work, it is not. The odds are that your intuition will lead you astray.

Some people think that they are saving time by just experimenting. Try a bunch of stuff and if it seems to work, then push it out.

But the better approach has always been to stand on the shoulders of giants. That is, in the same situation, you bounce out quickly and see what other people have done. Not in-depth research, but enough light reading that you can now make a better choice.

Do not make up your own way of doing things. Whatever you make up will end up costing you more time than you would have spent doing a bit of reading.

After you read stuff, you might not choose to follow it, and you certainly should never choose to follow it blindly. Instead, you might just build on what you’ve learned, and use that to improve how you do things.

If you rely on random guesses, then more often than not you will be wrong.

As you get more experienced, you’ll probably find that you dive blindly in far less often. You’re more likely to do some initial reading, look around for great references, and try to get some depth to your understanding first.

The more you know upfront, the better off things will go. You obviously don’t have time to know everything, so you do have to pick and choose, but more knowledge is always better than less knowledge. And getting knowledge from more experienced people is always far better than getting knowledge from overconfident ones.

Git Outta Here

I’m certainly not in love with Git. I’ve used far too many other types of nicer repos over the decades, but if you are going to use it, you need to use it properly.

At the high level, you have code that you packaged and released. Sometimes you need to just make a simple fix to that ‘exact’ code.

You need to ensure though that the code you are working on is exactly and only the code that you released. If your work habits or environment are messy, that is a difficult task fraught with a lot of uncertainty. But it does not have to be that way, and it should not be like that. If that happened, it is entirely self-inflicted.

So, a key development task is to ensure that that never happens. That is the primary reason for using a repo. Used correctly, most of them will guarantee that you know and can get a hold of the code that you released.

There are several different families of keeping the code organized, so most of the repo tools support a huge number of options. While that is great, it also opens up a hole for people to wantonly mix and match functionality, which is really bad. You can use a repo like Git to make your life easier, but you can also use it to make life a lot harder.

My advice is don’t mix and match. Pick one of the proper ways to use the repo first, learn it deeply, and then only when you really understand, tweak it carefully. For Git, Atlassian produced git-flow. You don’t have to use their tools, but you should strictly follow the branching model and do it carefully and properly.

For people who think that that sounds like more work, it isn’t. It follows the adage “a stitch in time saves nine”. That is for a little more effort up front, you’ll save yourself a whack load of time later; when you actually have less time than now.

Mixing and matching any sort of optionality is often called ‘going against the grain’, which comes from woodworking. If you sand with the grain of the wood, it will be easier and the results will be better. If you use the development tools properly, within a particular family of usage, they will work far better.

Ensuring that you get the exact code that you released earlier is part of another high-level principle, which is to never, ever, ever release untested code. If you haven’t tested it, you can not release it.

If some code does get released, it is because it was tested first. There are legendary examples of people causing huge problems because they violated this. But it is fundamental to every software release, large and small, critical or otherwise. It is the one rule that you should never violate. And if you violate it, it should not be accidental, but rather for some scary reason you needed to take that risk, and you were aware of the risk that you were taking. Accidental release or rollback of code is so easy to avoid, that any sort of excuse is lame.

If you can ensure that the code you released is easily available, then you can ensure that the code you are testing is also easily available. Your testing environment is akin to production. It is just another place you release stuff. In fact, every environment is just another place to release stuff, including development ones. The only difference with development is that people will change things directly, then retest.

If you get those types of guarantees then your repo tool is doing its job, working correctly for you. If you are not getting those types of guarantees, you need to fix your environments, they are broken. The mess is just making your life harder for no reason.

10x Developers

You can’t really type ten times faster than everyone else. It’s possible that the difference between the slowest, hunt-and-peck typist and a skilled touch typist is an order of magnitude, but programmers are not just blindly typing stuff in, so it doesn’t hold for coding.

The software industry likes to deny the existence of 10x coders, but for anyone who has worked for a long, long time, they’ve no doubt encountered them. A small number of programmers just seem to be pushing out way more work than all of the others. Why?

Since it’s not typing, we should narrow it down a little more.

A 10x software developer is at least ten times more “effective” than the average developer. That is, they accomplish more and their work has a much larger impact. They seem to be everywhere, working on all sorts of stuff, and it gets used a lot. The things they have done in the past have withstood the ravages of time, the stuff they are working on now is quite sophisticated.

So, what is it that makes the difference?

From what I’ve seen, they have a lot of knowledge and experience, but also they have exceptionally good habits. That is, a fast and reckless coder might keep pace with output, but their stuff is also a continual bugfest, so as more of it comes out, the deficiencies will multiply. Firefighting then consumes everything.

A 10x on the other hand codes a lot, but the code is good and clean and has very few prod issues. Things run smoothly. So they are able to spend even more time coding. They might not get off the starting gate as quickly as a fast and reckless programmer, but they can keep up their own pace for a very long time, so in the long run they get way more done.

The biggest habit they usually have is the need to fix problems when and where they find them.

Some coders will ignore all sorts of problems and just keep piling on more code, but that higher work is built on a shaky foundation. A 10x will start working, but then Yak Shave into some lower issue that needs to be corrected first. Then they’ll go lower, and still lower. Until the foundations are finally strong. Any code built on top then will require way less changes as the codebase gets larger.

So, the 10xes that I’ve worked with tend to be really slow in the initial stages of the work. But as they ensure that all of the pieces work as they expect, they whip past other developers. The last stuff, on top, comes easily.

You often see it when different programmers work. If they are struggling to set things up correctly in the beginning, they tend to pick up pace at the end. If they race quickly out of the gate in the beginning. then they often struggle at the end, which is also when we are the most tired and it is harder to think clearly about the code. If you have to choose, and you do, it is better to tackle all of the hard stuff first, when you have the most energy. Save the easy stuff for afterward.

10xes usually need things to be very organized. They need it to be clean, and they need to fix all of the other problems first before working their way to the main ones. They spend more time considering what they’ll call stuff, and less time playing with syntactic sugar. They’ll stop and consider future-proofing their code, not just settling on what appears to work today or what they saw on the web. Their speed comes from their need to produce quality work, not just kick stuff out the door.

10xes are super rare, and the industry does a lot to discourage them. Interviews, for example, favor fast and reckless coders with strong memories, not 10xes. A successful answer to some of the interview questions would be an objectionable way to code for actual production.

A software developer might find they are 10x in one organization, but then just be far less in another one, usually owning to the amount of systemic or project dysfunction circulating around them. But they are also affected by life issues and burnout. We code what we know, and if that is impaired for any reason, then our effectiveness is limited.

A good 10x will find a groove and get very solid stuff built. They’ll stay out of politics, and will generally wire their code to be flexible in the face of inevitable scope creep. They’ll use the programming languages well, but not abuse them. They value not just getting stuff to work, but also readability, how it fails, and whether it can be enhanced later.

They know what they know, and will talk about it confidently, but they also know what they don’t know and will tread lightly in discussions. They are quick to admit when they are wrong, and they know they are wrong often. Because of this, they are humble. The last thing they want to do is over-inflate their own abilities, so most of them would never, ever describe themselves as 10xers. They may have been in the past, but there is no guarantee that they will be in the future.

Realistically they alway need to do the right thing. To make sure they have done the best job possible, given whatever madness and impatience surround them. They take pride in their work and it shows. They tend to keep up with the industry gossip but stay out of most of the pointless arguments. They all seem to know that good work comes from concentrating on it, not just flailing at the keyboard and belting out more mindless stuff.

Amnesia

The single greatest problem in the software industry is amnesia.

It is people running around, pretending like a whole lot of stuff that happened, didn’t happen.

There is a persistent, but really mistaken belief that writing software is brand new, just started yesterday, and that because of that you can justify doing things incorrectly.

That is wrong. And you can’t really use “new” as an excuse anymore for sloppy work.

We’ve been writing software for over fifty years. It’s not new. Sure, about every five years, some “new” technology comes along and tries to disrupt everything, again, but those waves certainly don’t invalidate whatever else came before them.

Most “new” technologies aren’t even new. They are just retrograde recycles of earlier, but forgotten ideas. A slight twist on something a couple of generations back.

Somewhere around thirty years ago, true greenfield software development efforts started to vanish. Most things that can be handled by software, have been handled by software for a while. We’re just rewriting old stuff.

Most of the spins on any “new” idea in software are actually just small, rather routine, derivations on existing stuff. We’re rediscovering the same things, over and over.

At least 80% of the code written out there is routine. Most programmers will spend most of their time writing the same code that hundreds, if not thousands of other people before them have written.

And while we keep doing the same things over and over again, we reset ourselves to first principles every time. Forgetting all sorts of important stuff.

We did learn how to build things reliably. We forgot that. We did learn how to keep projects smooth and stable, but we forgot that too. We argued about how to express architecture, but all that was forgotten. We figured out ways to minimize our efforts, time and time again, and forgot each one shortly after we discovered it.

We could assemble reasonable methodologies, but we don’t. We could enforce better interface standards, but we won’t. We could build tools that would make our lives really easy, but they too got lost in the past.

It’s sad, but we constantly refuse to grow up. Instead, about every five years a new group of people comes along, ignores everything, and we just go right back to where we were before. Round and round we go. An endless cycle of relearning, and then forgetting, then relearning the same old things again.

I think we cultivate amnesia because newbies incorrectly think it would make their jobs more fun. The problem is that building stuff isn’t fun, it is just work. And continually going back to first principles, each time, with each new generation really isn’t fun either, it is just frustrating.

It is hard and painful to get out a new release. That is just the way it is. But foolishly trying to pretend like it should be a game instead has been just making it even harder and far more painful than necessary.

Building stuff will never be fun, but if you do it properly it can be satisfying. If you don’t want it to be a disaster, then learn from all of the people that came before you and figured out how to make it better. Ignore them at your own peril.