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.

I feel like the only thing you are actually good at is working by yourself because participating in a society seems far too difficult for you.

People further up the top of the hierarchy take the economic output of the ever decreasing number of work horses while contributing nothing but talk.

It is a humble observation, even if it was difficult for me to appreciate for such a long time.

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

[0] https://twitter.com/shit_hn_says?lang=cn

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.

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

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.

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 must be the most incongruous part of this post.

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.

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.

We need more artisans in the world.

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.

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.

Also, I would add:

I love clean code and auto-linting via perfectionist code rules that also auto-realign code to my standards of beauty.

I love using vim because it fits my self automation behavior and I've optimized it so much that I cannot use any other IDE without breaking things.

I am a Linux guy and I hate it when coworkers are too stupid for utf8 encoding.

I love tabs, not spaces and I don't understand it when coworkers are not able to setup a simple editorconfig file, hence integrate it in their "IDE".

I love working during the night because nobody is standing in my door while asking me whether I got that email two minutes ago.

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.

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.

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.

https://www.youtube.com/watch?v=g1ib43q3uXQ

I'm sure the project management guy hates it when his coworkers are too stupid to think of planning and deadlines.

I'm sure the product manager guy hates it when his coworkers are too stupid to think of users and use cases.

Good for you, but change management saves my time more often than not.

true master carry no sword