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.
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