Absolute truths I unlearned as junior developer

When you have to support legacy code with no docs, no specs, no tests, you change your mind pretty about the value of tests and a good specification.

As a senior engineering manager, I push hard to get good requirements for my team. Its being a sales person with the business side.

> Legacy code that I wrote myself is hard to read.

Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”

My goals used to be to write code that looked and felt cool to myself and others, to add features in clever ways with as little change to the function signatures and structure as possible so as to not disturb the architecture. While keeping changes small is a good goal to balance, it’s always possible to be too small and add unnamed concepts and fail to restructure around new concepts when you should. Do that a few times in a row (which I have done) and you end up with architectural spaghetti code that might look clean and modular at first glance but becomes a maintenance nightmare. My goals are now to: - make code so easy to read it’s boring, because if it looks interesting, it’s probably too clever - and to identify and name all the unnamed concepts and refactor often to accommodate new features.

- poorly executed cleanup (aka regressions)

- misunderstanding of requirements (new bugs)

- "standardization" of naming (now you have two standards https://xkcd.com/927/)

- restructuring of code/renaming of abstractions which then adds friction to original authors of code (provided they are still around)

Left unchecked this can all happen, at the expense of feature work, and an unmerged PR resulting in missed deadlines and a frustrated junior. Alas we usually learn best by making mistakes though and I find this one hard to teach for some juniors.

I would argue that a measured tolerance of ugly code (and sometimes bad code) is more important until you learn how to spot and write code that doesn't look wrong.

Two articles I found helpful:

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

I was upset, because people that seemed to be contributing less and were less-qualified (at least from my admittedly-biased perspective at the time) were promoted to a higher level than me, and I got a fairly form-letter-esque answer of "we don't have the budget to promote you this time".

The next cycle, they corrected it, and I was officially a "senior engineer" on paper, and I realized how silly my hissy-fit had been. Sure, I guess having a bit more money was nice, but it's not like it radically changed the quality of my life, it's not like having a fancy title changed how people really saw me, and I didn't even bother updating the title on LinkedIn.

I don't think I was "wrong" in what I said. I do think that I deserved the promotion over someone else, but at the same time, I also tarnished a relationship with my boss and coworkers, and I let it get me far more depressed than it should have.

-------

I guess if any "junior" engineers are reading this, try and remember that a title is simply that: a title. They don't matter a lot, try to not get too upset over them, and obsessing over something so nominal is a great way to build up anxiety.

EDIT: Just a note, I absolutely think you should call out a company if you feel like you're being taken for granted. I'm not advocating complacency, just make sure that your hatred is directed to the right places and try to avoid getting too depressed.