Sean Hickey
medium.com/@webseanhickey · Personal blog · on HN since 2014
Sean Hickey wrote a single Medium post, 'The Evolution of a Software Engineer', a humorous take on how coding style changes with seniority.
What HN saysHN links it as a joke about engineer maturity; one commenter calls it 'Stage 2: Do the approved thing' and warns about staying there too long.
16HN people shared it
5linked it in comments
11stories submitted
38story points
3 months agolast shared
2014people per year2026
Most-shared posts
- 1The Evolution of a Software Engineer16 people · 38 points · first shared 2014 · 3 comments on HN
What HN people wrote when they linked it
bhntr3 · 2021-04-03
Maturity (or seniority) is a form of growth and it has stages. I would call this article Stage 2: Do the approved thing.
It's an important stage. But people who stay in this stage too long become intolerable technical architects who yammer away about best practices and high level company goals, produce technical documents no one reads and plan team building events no one wants to attend.
To me stage 3 involves thinking critically about tradeoffs. Applying best practices in relevant contexts and rejecting them in others is a good example.
I always end up linking this silly blog post. https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer… It sums up the seniority growth cycle better than I can in words.
zer0defex · 2015-10-28
Being a technologist, I (we?) are probably more sensitive to technology presence in day-to-day life, so this strikes a chord. The joke of the evolution of a software engineer (https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer… has become reality, but for society in general.
Sometimes simplicity and lack of connectivity is for the better.
deepakkapoor · 2014-07-10
I have not looked at your code but I can say with some experience that it has nothing to do with how you wrote it. There is no way for me to confirm but most likely this is what happens when you turn in a coding test. Someone who is perhaps at a debatable senior level looks at your code and often (I have seen this happening at places where I have worked) gives it to someone else for their feedback. The person your code gets handed over to is often not the person who will make hiring decision. He/she will look at your code and try to discover their own style in your code. If your code does not come close to the way they would have written it then it is bad code.
A lot of things come into play here. Often it is unclear expections. I have done coding tests where the requirement was to pull data from a dataset and cache it in memory. This requirement can be met in many ways. I chose the simplest one but the feedback I got was similar to what you got. It totally depends on where the reader of your code is in the evolutionary stage https://medium.com/@webseanhickey/the-evolution-of-a-software-engineer…
Reading code is harder than writing.