<story><title>Levels of Seniority</title><url>https://roadmap.sh/guides/levels-of-seniority</url></story><parent_chain><item><author>JamesBarney</author><text>Woah my experience is completely different.  I&amp;#x27;ve never seen a product fail because of poor engineering practices.  And I&amp;#x27;ve seen plenty fail because of business issues.&lt;p&gt;I&amp;#x27;ve worked mostly on enterprise software, many of which had awful code bases but we&amp;#x27;re wildly profitable.</text></item><item><author>aero142</author><text>You picked the easiest strawmen out of his examples to knock down in short funtions and DRY. The other examples were, no QA, no code reviews, which are things that I have seen first hand, combined with the other complains, to code that is always in a half broken state. The code is very difficult to change so you spend all of your time on support cases. Re-writes have their own pitfalls. Ultimately, developer retention and hiring suffer because no one wants to work on these products. The institutional knowledge leaves through attrition and it takes too long for new developers to learn to be productive in the code base. Eventually the quality of the product declines until customers leave. So, even highly profitable products die because of poor engineering practices. There are certainly engineers that get caught up in know-it-all platitudes, but I&amp;#x27;ve personally seen more profitable products fail because of poor engineering practices than good engineering practices fail because of poor business sense. YMMV, but in my experience, good engineering is more rare than good business ideas.</text></item><item><author>cle</author><text>It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much.  You know what’s way more important than short functions and programming platitudes like DRY?  Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.</text></item><item><author>leto_ii</author><text>Many of the points made in the article seem pertinent to me, however I think thinking in terms of discrete levels of seniority is counterproductive. I also think that there isn&amp;#x27;t a single dimension of seniority that we should talk about.&lt;p&gt;To give a precise example, in my previous job we had very hierarchically senior people who understood the industry and the business side very well and of course knew the company&amp;#x27;s platform very well. Oh the other hand, strictly in terms of technical competence I think they lacked a lot of the basic mental framework. Their code was atrocious (core code in classes of 1000+ lines with no documentation or tests, lots of copy-paste), their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff, no code reviews, no QA etc.).&lt;p&gt;This kind of people in some ways would rank as competent architects and in some other ways as fitting the good old adage &amp;quot;20 years of experience - the same year repeated 20 times&amp;quot;.</text></item></parent_chain><comment><author>ivanhoe</author><text>What kills those products is not the bad code itself, it&amp;#x27;s the side-effects piling up: added dev expanses, lagging behind the competition in adding new features, performance problems as app grows, etc. Badly written code is simply more expensive to maintain and improve. I guess it&amp;#x27;s less of an issue if you have a very profitable product and&amp;#x2F;or enterprise clients who are much more tolerable to things like the simplest customization taking weeks to finish, integrations that are complicated and cost thousands and thousands of dollars, etc. For startups and smaller businesses that are tight on dev budgets it&amp;#x27;s much bigger of an issue.</text></comment>
<story><title>Levels of Seniority</title><url>https://roadmap.sh/guides/levels-of-seniority</url></story><parent_chain><item><author>JamesBarney</author><text>Woah my experience is completely different.  I&amp;#x27;ve never seen a product fail because of poor engineering practices.  And I&amp;#x27;ve seen plenty fail because of business issues.&lt;p&gt;I&amp;#x27;ve worked mostly on enterprise software, many of which had awful code bases but we&amp;#x27;re wildly profitable.</text></item><item><author>aero142</author><text>You picked the easiest strawmen out of his examples to knock down in short funtions and DRY. The other examples were, no QA, no code reviews, which are things that I have seen first hand, combined with the other complains, to code that is always in a half broken state. The code is very difficult to change so you spend all of your time on support cases. Re-writes have their own pitfalls. Ultimately, developer retention and hiring suffer because no one wants to work on these products. The institutional knowledge leaves through attrition and it takes too long for new developers to learn to be productive in the code base. Eventually the quality of the product declines until customers leave. So, even highly profitable products die because of poor engineering practices. There are certainly engineers that get caught up in know-it-all platitudes, but I&amp;#x27;ve personally seen more profitable products fail because of poor engineering practices than good engineering practices fail because of poor business sense. YMMV, but in my experience, good engineering is more rare than good business ideas.</text></item><item><author>cle</author><text>It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much.  You know what’s way more important than short functions and programming platitudes like DRY?  Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.</text></item><item><author>leto_ii</author><text>Many of the points made in the article seem pertinent to me, however I think thinking in terms of discrete levels of seniority is counterproductive. I also think that there isn&amp;#x27;t a single dimension of seniority that we should talk about.&lt;p&gt;To give a precise example, in my previous job we had very hierarchically senior people who understood the industry and the business side very well and of course knew the company&amp;#x27;s platform very well. Oh the other hand, strictly in terms of technical competence I think they lacked a lot of the basic mental framework. Their code was atrocious (core code in classes of 1000+ lines with no documentation or tests, lots of copy-paste), their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff, no code reviews, no QA etc.).&lt;p&gt;This kind of people in some ways would rank as competent architects and in some other ways as fitting the good old adage &amp;quot;20 years of experience - the same year repeated 20 times&amp;quot;.</text></item></parent_chain><comment><author>hinkley</author><text>My best bosses and I think every mentor I&amp;#x27;ve ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there.&lt;p&gt;Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite).&lt;p&gt;I think the saddest &amp;#x27;joke&amp;#x27; I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn&amp;#x27;t work out that great, did it?).&lt;p&gt;Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don&amp;#x27;t experience shame the way the rest of us do.&lt;p&gt;In theory, XP&amp;#x27;s theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog.&lt;p&gt;Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers &lt;i&gt;less&lt;/i&gt; time to think. Oops.</text></comment>