Hacker News Reader

Comment by rootusrootus | Hacker News Reader

> What’s amazing is that I keep getting “exceeds expectations” ratings for this work because I ship things PMs want.

This is surprisingly underrated, I know a lot of senior engineers that struggle with it. The best thing I ever did for my career when I started professional software development was realize that my manager and my customers did not care about tech stack choices, or perfect software. All they cared about was that it shipped, and in a reasonable time. They could handle some bugs as long as I fixed them.

I still have to tell some engineers with 10-15 years experience to stop navel gazing over the tech choices, and get the damn software out the door already.

View on HN

> I still have to tell some engineers with 10-15 years experience to stop navel gazing over the tech choices, and get the damn software out the door already.

This may be an unpopular thing to say, but at most companies, you should have less senior engineers than that doing nearly all of the "get the damn software out the door already" work. The 10-15 years experience people should really be doing work with broader impact than that. And this isn't to downplay the importance of that just-get-things-done role at all! It's critically important. But it's a ratio thing; most companies should have a lot of earlier career folks implementing things and a few later career (or just very high achieving) folks setting technical direction, discovering and advocating for new projects, yada yada yada. I think the truth is that lots of places have this ratio out of whack with respect to the actual availability of impactful projects to work on. If there isn't enough work for folks at Staff level and above beyond just knocking out crud apps, you've got a mismatch.

We subscribe to this philosophy on paper and it works out pretty poorly. The best managers and teams are the ones that manage to subvert it.

There's a pretty wide variation in efficacy at doing the mainstream work. It's good to retain and reward the people who are good at it, so that they make up a higher proportion of the ones doing it. Otherwise you're constantly throwing away good people and replacing them with new hires of lower/unknown quality, just because you don't have enough "strategic direction" type work to promote them.

Yeah... I guess it depends on the person. I personally felt like "just get the work out the door" lost its novelty / interest for me after about five years doing it and that I spent the next five years becoming increasingly unsatisfied with my work after that. It is more satisfying for me to have more scope over larger projects. But not every place has that kind of work available. But "just crank out the bread and butter work instead" is not a solution either, because like I said, I find that unsatisfying. So if there isn't "strategic direction" type work, for some people the choice isn't between "throwing away good people" vs. keeping them doing the bread and butter work; they are going to seek greener pastures for the kind of work they prefer doing either way. There are other people who really enjoy just knocking things out no matter how long they do it, and I agree with you that many organizations would benefit more from having lots of that kind of person.

I left my past company in part because all they cared about was shipping by some ridiculous time frame.

While it certainly helped my ability to look good to PMs and other programmers, it made for un-scalable, un-readable, and un-maintainable code. My company lost tons of developers due to the constant punting of code debt. It might be easy to say push back on clients but the dev team rarely had that ability unless it was a nice client. Ugh, so glad I found a better company.

Change your team or company every 2 years. Always pick greenfield projects so you can feed your tech stack curiosity. Code usually starts to rot in 18 months mark.

Nobody cares about high quality code in a corporate environment neither should you. They're going to toss your code out of the window when some MBA from McKinsey & Co. comes and do "cost structuring" for your corporate.

Keep your craft for your open source projects if you _really_ want to do it. It's your code and it really matters to humanity if you make something good in th open.

I think there's an important distinction between ridiculous and reasonable time frames. If you're forced into releasing bad code because of an arbitrary deadline, then that is a problem. But I see plenty of the opposite, where programmers are so focused on perfecting their code that they fail to realize that software which never ships isn't software, it's just art.

It really isn't hard to ship perfectly good code relatively fast. I think most times when people have trouble getting code out the door without causing serious tech debt, it's because they've gone down the premature optimization rabbit hole and introduced a lot of unnecessary complications anticipating some future that doesn't yet exist.

Reply on news.ycombinator.com