<story><title>Levels of Seniority</title><url>https://roadmap.sh/guides/levels-of-seniority</url></story><parent_chain><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>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></comment>
<story><title>Levels of Seniority</title><url>https://roadmap.sh/guides/levels-of-seniority</url></story><parent_chain><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>rootusrootus</author><text>This deserves more upvotes.  I have met so many engineers who do themselves a disservice by overvaluing the esoteric bits of code that nobody but their team will ever see.  The business doesn&amp;#x27;t care as long as it works, and soon.  Which isn&amp;#x27;t to say that you shouldn&amp;#x27;t sometimes sweat the small stuff, but you always have to remember that you&amp;#x27;re working for a &lt;i&gt;business&lt;/i&gt;.</text></comment>