4 ms·

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 PM

by colmvp 5y ago

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.

msoad 5y ago
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.
rootusrootus 5y ago
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.

4 ms·

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 PM

by colmvp 5y ago

msoad 5y ago
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.
rootusrootus 5y ago
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.