One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One dev can do in one month what two devs can do in two months
That's always possibly true, but it's especially true if you have multiple devs that are individually very good, very opinionated and who love to argue. And oh boy do developers love to argue!
At a previous job the front-end team was stuck for two or three weeks because there were passionate debates on how TypeScript imports should be ordered. PRs could not be merged before this was resolved because each one was reverting the imports in the "right" order. I'm not a front-end dev myself, so if someone knows why that's important, I would love to get to the bottom of this, even if it takes one month of hard work.
Some things are too important to be debated comes to mind ... ;)
Edit - Define "good". A big motivation for me with these articles is to redefine the meaning of the word "good developer". Today unfortunately, it's abused, and misunderstood, such that the dev that knows the most complex theory is perceived as "the best" - While often the exact opposite is true, as in the more pragmatic developer is better for all practical concerns. I once spent two hours quarrelling with a colleague over UTC best practices. Interestingly, we were mostly in agreement, something I tried to emphasise (in vain) to get out of the fight. However, he was persistent, and refused to stop shouting, until I showed him a Jon Skeet blog where my argument originated from.
Objective this guy was better than me. However, I created in 30 minutes what he failed to create in 4.5 months. Yet again, define "good" ... :/
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
Define "good". A big motivation for me with these articles is to redefine the meaning of the word "good developer".
That's a great question.
I would differentiate solo projects and working in a team.
For solo projects, do whatever makes you happy and productive.
Want to program in Haskell? Go for it.
When working in a team, I wish we had something like the Serenity Prayer
Lord, grant me the serenity
to accept the things that I don't love but are fine nonetheless;
courage to insist on things that really matter
and wisdom to know the difference.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article.
That's always possibly true, but it's especially true if you have multiple devs that are individually very good, very opinionated and who love to argue. And oh boy do developers love to argue!
At a previous job the front-end team was stuck for two or three weeks because there were passionate debates on how TypeScript imports should be ordered. PRs could not be merged before this was resolved because each one was reverting the imports in the "right" order. I'm not a front-end dev myself, so if someone knows why that's important, I would love to get to the bottom of this, even if it takes one month of hard work.
Hahahahaha :D
Some things are too important to be debated comes to mind ... ;)
Edit - Define "good". A big motivation for me with these articles is to redefine the meaning of the word "good developer". Today unfortunately, it's abused, and misunderstood, such that the dev that knows the most complex theory is perceived as "the best" - While often the exact opposite is true, as in the more pragmatic developer is better for all practical concerns. I once spent two hours quarrelling with a colleague over UTC best practices. Interestingly, we were mostly in agreement, something I tried to emphasise (in vain) to get out of the fight. However, he was persistent, and refused to stop shouting, until I showed him a Jon Skeet blog where my argument originated from.
Objective this guy was better than me. However, I created in 30 minutes what he failed to create in 4.5 months. Yet again, define "good" ... :/
That's a great question.
I would differentiate solo projects and working in a team.
For solo projects, do whatever makes you happy and productive.
Want to program in Haskell? Go for it.
When working in a team, I wish we had something like the Serenity Prayer