I'm Michelangelo - but that by definition makes me a loner.
I love staring at my code and contemplate on it's beauty just like the result of the code working.
I'm perfect at one-man projects.
I hate processes, standups, scrums and all that team playing bullshit.
I love customers and bosses who are trusting and freedom giving.
I love beers, steaks, good food and team gatherings - and i love people whom i am "working" with - but everyone knows i am working on something that is NOT "let get this shit done quickly and push this out of the door by next friday". That's not me.
Although I'm the one my boss comes to with "i don't know how but can you do something about it tomorrow"?
I'm good and super sharp focusing and delivering on my own.
If i need help - I'll ask.
I'm all for skunkworks.
I debug my code myself, using techniques i polished myself over the years and I'll end up with lightbulb that will last 100 yrs. Not the one that cost $3 and requires full replacement after 3.5 weeks of light usage.
I try not to buy stuff made in China. I love stuff made in Europe or Japan.
So, don't push guys like me into your "processes" and "change managements" wasting pipeline bullshit.
I won't fit.
I speak at conferences. I do evil harmless things. I violate countless stupid compliance rules. I take risks no one knows about.
I don't follow rules, and pretty much skip reading them when i can.
I do my best to deliver masterpieces. One piece at a time.
I think the post was saying that different folks have different skills and we should give people the space to do what they enjoy. I agree with it, and somewhat fit the archetype of "Fred" in the post.
That said, I could only nod along with the first half of your comment - the rest started to get a bit condescending.
I mean, you do you - if this working style works for you, that's great! But I think you can still work on your craft and be a perfectionist while appreciating how others want to work as well.
This emergent phenomenon is pretty much hard-coded in humans. Vide: the entire human history. Confer: multiple social experiments of building "the perfect society".
Each animal can be said to posses a survival strategy; ours resides not in talons, or rapid flight, or keen perception, or camouflage, but in cooperation. Even the hierarchical structure of our social organization aids in this.
It is a humble observation, even if it was difficult for me to appreciate for such a long time.
Sure. But if your are actually as flippant as this response indicates then why make it. Certainly why make it on the internet whose only goal is to provide more efficient societal connections.
Engineering beauty is when form follows function. A hundred year bulb that will only be used for 5 minutes is ugly and imperfect
One that lasts 3.5 weeks is still ugly, but one that last 20m +/- 15 is beautiful, and one that lasts 10min +5/-5 is a masterpiece. An engineer still wants a safety factor, after all
It goes both ways: I hate shipping ugly code, which makes me a slow coder. On the other hand I love spending weeks refactoring pieces of code which will have no repercussions on the end user but will make life easier to the rest of the team.
I've also been accumulating home-made scripts for debugging and such for the last 10 years. The fact that I made them makes them more powerful.
I don't think I've ever seen this combination of "very much cares about code quality" and "slow coder". Most of the clean code fanatics I've seen (and I include myself), are also very quick to deliver features - whereas developers who simply try to complete the feature in the shortest possible time, usually end up taking longer, because their quickly written code is buggy, then hard to read, and so hard to debug and fix.
It's not usually a choice between, leaving the code as it is (and just adding a bit of functionality), or refactoring to make it better. It's usually a choice between making it worse, or making it better. So the developers who aren't Fred, are making things worse. I try to make refactoring and keeping the code clean part of every team members' job description. It's often hard to get the business to schedule time for this sort of thing, so it should just get built into the time for each task. As for automating tasks which could be automated - seriously, if you have developers who are not doing this, then they are the problem, not Fred.
I don't think I've ever seen this combination of "very much cares about code quality" and "slow coder".
I humbly submit that you have been exceptionally lucky in that case, unless you're quite new to the industry. We've had problems with dogmatic developers and architecture astronauts for as long as software development has been a thing.
In the 1990s, they were the ones trying to shoehorn as many design patterns as possible into every OO project. There was little evidence that doing so made the code better in any material way, but that didn't matter, because Design Patterns Are Good Things.
In the 2000s, they were the ones adding lots of artificial complexity to otherwise reasonable designs to enable their preferred test automation tool to hook in everywhere. There was little evidence that enforcing these rules universally actually improved quality or saved time, but Everything Must Be Unit Tested.
In the 2010s, they were the ones refactoring anything with more than five lines in a function or more than one level of nesting. There was little evidence that this improved any important code metrics, and even some evidence that it actually made things worse, but the longer or deeper version violated someone's arbitrary list of Code Smells That Are Bad so it had to be fixed.
A recurring theme here is taking the essence of a reasonable idea that might be useful in some circumstances but then applying it with an absurd degree of rigidity and scope without regard for the cost-benefit trade-offs being made. XP advocates even made this the centrepiece of their philosophy, though XP was born out of a project that was hardly a great success...
I’ll upvote, not downvote since this is worthy of discussion.
First observation... This stance only works if you’re so talented that you can succeed without outside help, and you have a boss that respects your value and can take ownership of building bridges for you. Those bosses are rare.
Observation two... Building bridges and helping others makes it easier, not harder, to get things done.
Observation three... Some people who take this stance aren’t worth it. Many folks take this stance to purposefully close their ears to ideas that could be useful.
Observation four... The person referenced in the article is someone who can be a huge net positive in building developer tools.
I think the GP is describing an artistic/hobbyist view of software development. If you're doing it purely for your own enjoyment, with no external requirements to constrain you, you can take all the time you want and follow whatever process you want and try to achieve whatever you consider to be perfection.
This contrasts sharply with professional software development, where you are building software for a purpose and often within a specified budget and timescales. In this case, you can't be selfish any more, because the whole reason for what you're doing is to satisfy the need of someone else. Processes and tools that you can happily ignore on your fun projects become relevant. Being unwilling or unable to work effectively with other developers or with people who have different roles on the project team makes you almost worthless. Taking risks that no-one else knows about becomes a danger to the whole project. Your goal isn't to achieve perfection, it's to deliver software that meets the requirements, on time, on budget, to an acceptable standard.
This is me as well. It really hit home when I was talking with a friend about not joining a company that's just trying to get stuff out the door quickly. She said "you're an artisan, you just want to practice your art! And that's hard to do at some places."
I do really like that analogy, of artisanship or craftsmanship. I understand the business need to move quickly, but over time I've found myself more intrinsically motivated by building what I think of as well-designed systems. That, to me, is art. That's what I get excited about. I'd also like to think that some of the extra time I spend upfront is saved down the road when things don't break. I think great engineering cultures respect that balance.
> over time I've found myself more intrinsically motivated by building what I think of as well-designed systems. That, to me, is art. That's what I get excited about.
Me too.
But art without constraints is boring. What gets me off is building the most perfect well designed system possible within the constraint of shipping things that solve real problems for real people and the business.
I tend to refractor too much but that kind-of makes me terrible at one-man projects, since I know enough about my code to see all the mistakes and all the possibilities, working with others, even if I do sometimes begrudge it, forces me to take a bigger picture look at things and say this is good enough.
Probably the ideal thing for me is to do a project where I am coordinating with others but they are working independently, like microservices for instance where you can look at the back end and say this looks like crap let me tear it up without blocking anyone else's progress.
So I'm surprised by the assertion that that sort of code perfectionism is good for one-man projects, but to each their own.
I mean pivot this a little bit and you could easily make this about some hipster coffee snob, some PC gaming supremacist, or whatever else society has arbitrarily decided is elitist snobbery over a maestro executing art.
The worst part about manifestos like this is when they enable people who think they're this good when really they are subject to the Dunning-Kruger effect.
There is growth in fully understanding that perfect is enemy of good enough. Perfect systems not deployed have no value and don't create wage paying revenue. As in all things, balance is important. Anything is good enough is the opposite problem.
>I am a Linux guy and I hate it when co-workers are too stupid for utf8 encoding.
You sound like a jerk. Team-mates not understand something is not an excuse to call them stupid. If you truly love something then usually you'd want to share that love with the uninitiated.
> Speaking from experience; once it’s been shared ad nauseam, and they still don’t get it, what would be the alternative conclusion?
Your not sharing it in a way that's understandable?
People learn and think about things in different ways. An explanation for something that's clear to you might be gibberish to me. Continuing to explain it to me in a way you understand doesn't really help me.
> Your not sharing it in a way that's understandable?
In my experience, people develop a better understanding of a particular concept if they take the time to figure it out for themselves rather than relying on someone to explain it to them.
The person might not be able to figure it out on their own. That doesn't mean they're dumb; they just missed a particular intuitive leap that was easier for you.
The person might dive into it and learn it incorrectly. They might find something on the internet that seems to make sense, but isn't a good way of doing it. Then you have to clean up the mess their imperfect understanding caused, plus help them unlearn the wrong thing.
I think the best bit is somewhere in between. When learning something new, everyone should do some of their own research and self-teaching. But having someone knowledgeable to also teach can be essential, and if someone like that is available, I think it's wise for a self-learner to at least check their understanding with that person, early on.
You sound like the guy at my work who pushed a 'perfect' change on a Friday afternoon and backed up my queue of tickets for the next 2 weeks. I had to purge several days of automated processes, take a few days to manually process it all after fixing issues induced from the change, then took another week to catch up on what was on hold.
Good for you, but change management saves my time more often than not.
I'm with you (in a slightly less over the top style.) Bootlickers like the author of this blog are why everything is riddled with functionality and security bugs.
I hate shitty band-aid code. I love perfection.
I'm Michelangelo - but that by definition makes me a loner. I love staring at my code and contemplate on it's beauty just like the result of the code working.
I'm perfect at one-man projects.
I hate processes, standups, scrums and all that team playing bullshit.
I love customers and bosses who are trusting and freedom giving.
I love beers, steaks, good food and team gatherings - and i love people whom i am "working" with - but everyone knows i am working on something that is NOT "let get this shit done quickly and push this out of the door by next friday". That's not me.
Although I'm the one my boss comes to with "i don't know how but can you do something about it tomorrow"? I'm good and super sharp focusing and delivering on my own. If i need help - I'll ask.
I'm all for skunkworks.
I debug my code myself, using techniques i polished myself over the years and I'll end up with lightbulb that will last 100 yrs. Not the one that cost $3 and requires full replacement after 3.5 weeks of light usage.
I try not to buy stuff made in China. I love stuff made in Europe or Japan.
So, don't push guys like me into your "processes" and "change managements" wasting pipeline bullshit.
I won't fit.
I speak at conferences. I do evil harmless things. I violate countless stupid compliance rules. I take risks no one knows about. I don't follow rules, and pretty much skip reading them when i can.
I do my best to deliver masterpieces. One piece at a time.
Downvote me.