Newbie Mistakes

 Mistakes:

• Change the “least” amount of stuff.

A huge mistake. If you make a change to something, you have to make it consistently, everywhere. Otherwise, in the not too distanced future, you will have to do that change again in one of the other locations. The problem is that until then you have to remember that you needed to make this change. Remembering that you need to make 1 or 2 changes isn’t taxing, but if you keep doing it, and there are hundreds of things you were supposed to remember, then quite obviously a whole bunch of them will be forgotten. However, if you do the change everywhere, you can forget about it. It will not crop up in the future as a problem. Way, way fewer things to remember.

• Only release a “part” of the system.

Another tragic mistake. Unless all of the parts of the system are ‘completely’ independent of each other, those dependencies will quickly build up into a big problem. Again, keeping track of what parts were changed and when is far too taxing, so it will eventually become forgotten, causing preventable problems. It’s far safer to release ‘one’ system than it is to release 20+ subparts.

• The names of things don’t matter.

This is a rather deep problem. Obviously, you don’t want to be working on a system where it has a variable called ‘foo’, only to find out that there are no ‘foos’ in that variable but instead it is full of ‘bars’. That is a great recipe for wasting time. Pretty much all ‘usable’ code will eventually be worked on by a lot of other programmers, so if the name is incorrect, or weird, and you waste their time, they have a right to be angry about it. We don’t just write code for ourselves, that would only ever be a ‘hobby’ system, not a real one. If it’s real code, it needs to be done correctly. Now it’s true that a lot of people feel that naming is ‘hard’, but that doesn’t mean you should do it badly or misname stuff. Rather, it just means that it is one of those parts of software development that needs more effort and concentration, not less.

• Any code that works is good enough.

That is true for a throwaway demo. That is not true for getting a big system to be stable. At that scale, bad code is worse than no code. Thus, a giant pile of bad code is a negative contribution. If the code works most days then it is going to create a lot of operational headaches on its bad days. That drama eats away at all other aspects of the project and often ends up killing it. It diverts the focus away from doing the right work, often causing everything to spiral out of control. If you can’t code it correctly, you should not code it at all. You’re doing the project a favor.

• Learn by doing.

It’s not a bad idea to go out and get experience. If what you are doing is fairly simple, it is fine to go back to first principles, start at the beginning and work your way through the issues. That’s the way education works. A set of good University courses combines theory and practice, with each following course getting a little harder. The mistake, however, is to jump straight into the deep end without ever having bothered to learn how to swim. For something that is complicated -- like some parts of system development -- if you go all of the way back to first principles, it will take you at least 40 years to catch up to the current state of the art. Too much water has already passed under that bridge, What you need to do is seek out knowledge and mentors. They can help you learn way, way faster, and thus narrow the gap between doing the work and being competent at it. Once you have acquired that knowledge then you can start honing your skills, and again it is way faster to do that while working with a team of experienced developers than flailing around on your own trying to reinvent wheels.