Comment by astockwell | Hacker News Reader

Comment by astockwell | Hacker News Reader

I toiled like you seem to be for a long time, cleaning up technical debt, and writing well-architected (but very time-consuming) code. I learned a few things (things I have to remind myself of often, when I too feel the anger rising at people who don't place the same priority on those things):

The business is almost never paying to you clean up technical debt. They are paying you to generate revenue (or save costs). Period. It could be the best architected system in the world, but if it takes 4x as long to build, and the "quick and dirty" version can ship and generate revenue earlier, then that is the way the business will want to go (even with an elevated error/loss rate). My takeaway: If you do not intimately understand exactly how what you do each day makes the business more money, or saves the business more money, then you need to pause and figure that out.

Nobody gets credit for building a system that never goes down. It does not speak for itself (much as I would like it to). As others have pointed out, it's critical to communicate the value (see point above) of what you are doing, and communicate it to the people who matter.

Dealing with Humans (incompetent and otherwise) is actually what most of us get paid for (or at least it's a big share of why we get paid). Dealing with bureaucracy, red tape, incompetence, things taking too long, etc... Sometimes I wonder why I have to wait for others who are slow, don't they realize how much money is being wasted?! But it's true, the human component of our jobs is the main reason why we haven't already been replaced by others/computers. Relationships trump even adding business value (point 1 above): if you are difficult to work with, but add value, you will still be marginalized (or even let go). However on the flip side, if you are great to get along with but do little-to-nothing, you may not thrive, but you will survive.

> They are paying you to generate revenue (or save costs).

One of the senior engineers in my company once told me, "business is the dog, technology its tail", not the other way around. While I later argued with a completely different set of engineers that the analogy isn't great, the gist of the idea remains valid: we shouldn't be building beautiful technology just for the sake of it. Rather, we should be building technology that will serve the business best, while balancing out short-term and long-term gains.

> Dealing with Humans (incompetent and otherwise) is actually what most of us get paid for

This is so true as well. I often realize that the problems I solve at work aren't exactly rocket-science. However, I have learned a bit about effectively interacting with humans, and that is probably more important to my company than my pure technical skills.

I didn't have any of these skills and I am still learning. However, I'd HIGHLY recommend the following "The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change" for anyone wanting to learn soft skills.

You don't get to do it right until version 3.

You write version 1 quick and dirty to get it out the door fast. Version 1 is written to acquire customers. You write version 2 to patch over all the problems of version 1. Version 2 is written to retain customers, but it ends up as an unmaintainable mess.

In version 3, you finally get to throw out the old code base and take the time to write clean, architected, maintainable code. Version 3 is written to attract and retain developers. Once it reaches parity with version 2, you can do the "Big Migration", and then start adding features. Version 4 and up are all built on 3, but barely anyone ever gets that far.

Note that this won't match up with the version numbers written into the software. You can't do anything about those, because marketing and management tells you what they have to be. Anecdotally, most software projects never progress past version 2, no matter how high their marketing numbers go. This is because version 3 does not directly add to the bottom line. It adds to developer productivity, and if the company cannot measure the value of developer productivity already, there will never be a business case for it. We all want to work on version 1 or version 3, because version 2 is a never-ending nightmare slog of one problem after another, but version 2 is that gaping hole that businesses will just keep throwing their money into, forever. And version 4 is easy and boring, where the only hard work is in upholding the process that is keeping the less experienced coders from cluttering up the place.

OP's mistake was in writing version 3 before telling management why that would be a "Good Idea That Saves Money" and seeking their mandate, and in not owning the successful completion as a major accomplishment. OP's current manager always understood that people run the company, not the code. That's not incompetent; it's a competence OP doesn't currently understand.

There's so much wisdom in the post.

>The business is almost never paying to you clean up technical debt. They are paying you to generate revenue (or save costs). Period.

So true. Once you're in enterprise nobody cares that you wrote the connection pool yourself (which I did and nobody gave a darn). I did 5 years in enterprise and decided that was enough for a lifetime.

>Nobody gets credit for building a system that never goes down.

This happened to me. I designed and wrote a subsystem that is used by every GM dealership around the world and that thing never went down meanwhile my colleagues project was always down yet folks from the other team were the ones that got promoted.

Probably made it look too easy. That'll get you nowhere.

so true lol.

Reply on news.ycombinator.com