Spot on, intel immediately comes to mind. Will playing it safe always lead to mediocrity though? Depends i guess, heard that a good poker player loses less often.
(edit) Enjoyed reading the rest of the article too. In the environmental impact section i missed the idea of using more efficient languages though.
Loved your article "Learnings from six months as a first-time engineering manager" too. I was instantly reminded of the documentary on Michael Schuhmacher on Netflix i watched yesterday. I couldn't care less about Formula 1, but still think that it is an amazing movie and great role model for good leadership. He was asked over radio after he won the championship: "How do you feel?" There are several seconds of silence. He answers: "Ross you are the best. You guys are all great. We did it." I thought: "Wow, he puts the others before himself. A great example of a good King after the theory of archetypes by C.G. Jung"
> 3. Good software is aesthetic
>
> Take a moment to step back and look at your code.
> It should look beautiful to you.
> ...
I can understand feeling pride in your work and all that, but let's not pretend--the code I write today is probably best viewed through beer-goggles, not in a wedding dress :D
> If you don't hate your code enough to throw it away and replace it on a whim, then you've made it more important than it should be.
You shouldn't write code you hate just to avoid attachment. What you should do instead is to develop the ability to (as product designers tend to say) "kill your darlings". You should love the code you create, but you should love the freedom even more that comes with being able to wipe it away with one stroke. Like sand drawings in a zen garden you should accept that nothing is ever final and don't let the things you created excert power over you.
You can also be proud of what you created as well, not because the thing is the thing it is, but because you made it and you were happy with how it turned out under the circumstances of the moment, maybe you even learned some things. Circumstances and the whole world change (including you), so what you created might not be up to the task anymore, you might be able to create something even better, more reduces, more clear, etc.
And you can feel all that while still happily throwing away your code. It is not a contradicition.
Good design is not lost once you are done with it. The lessons learned when following through with such things stay and ultimately enable you to build more better things faster.
But if I were the CEO/Manager/etc. I guess I would mind.
> 8. Good software is thorough down to the last detail
That's my approach. It tends to earn me a bit of scorn, but I do it anyway.
In my case, that turns out not to be the case. I work very quickly.
I can develop a fairly "full-fat" iOS app, with a lot of functionality, in less than a week. I do it all the time, with test harnesses.
But getting the app to what I consider "ship" shape, is another matter entirely, and can stretch the project to a couple of months (which is still not so bad, all things considered).
One of the nice things about my approach, is that I can start using TestFlight (Apple's beta-test service for iOS) quite quickly. This allows non-tech stakeholders to start actually using the app, very early in the process.
If I have an open-ended schedule (like I do, with the project I'm working on now), it's amazing, because we can refine the project, and work through a lot of the MVP stuff, without the public shame.
Most people seem to be content with good enough and that is fine too. Diversity makes it fun somehow, there would be way less to discover and learn if we were all alike.
Maybe striving for greatness instead of perfection might be a way?
P.S.: Bookmarked your stuff last time you commented about testing harnesses and stuff. Haven't done iOS work in years and may never need it. I treasure a work ethic like yours, keep it up.
It's a labor of love, and I feel that makes all the difference. I like to think of what I do as a "craft."
1. Good software is carefully balanced
a good software is created when the user requirements are carefully balanced against resource and time constraints.
2. Good software is joyful to handle
A truly good software should invoke the child like playful and joyful instincts in the users.
E.g. tell me how many times you've read an article about Jony Ive versus about an important software engineer at Apple.
Maybe no articles written about them but books or chapters ([0], [1]) written by them.
In the spotlight? You betcha, i think watching talks by Brian Cantrill is highly entertaining. Rich Rickeys' talks are highly regarded on HN (making a mental note to watch them). Carmack talking at Quakecon for hours about many different things.
(edit) formatting and links
[0] https://www.amazon.com/Coders-Work-Reflections-Craft-Program...
[1] https://www.amazon.com/Masterminds-Programming-Conversations...
Chris Lattner (inventor of LLVM and Swift) was pretty prominent when he was at Apple. He got stage time during at least one keynote and was well known in the macOS/iOS community. Not to mention that their engineering leads in general get to present their work every year to the devs who will be using it during the WWDC sessions.
But Carmack is from a generation where developers were often still working on something on their own.
I do see a shift to a model where developers are viewed more as a commodity and less as artists. In a "just throw more developers at the problem" kind of way.
`Code isn't "clever" if no-one understands it.`
It will make some code-bros mad though.
I always wonder what modern UI would look like guided by these principles... I am a full-stack product designer.
The Linux Mint team did a blog post on changes in a new version. The tweaks on the design were really subtle, increasing contrast here and there to improve access- & readability. Back then i tought: "So what?"; now i think this is the correct way to do it.
The best would be a native executable with no required server component.
Good design is needed everywhere. It's much more than adding a gradient to a Buy button.
Why are these supposed to be special? Everyone would agree with these in theory but the problem is not lack of these principles, the problem is how to actually use them in a fast moving business with imperfect tools, imperfect knowledge, imperfect employees and changing goals.
If you looked at my systems, you might say I am not following the principles but I was and am, they just don't always work very well in real life.
Not me - when I read "Take a moment to step back and look at your code. It should look beautiful to you", my bullshit detector goes off full-tilt. The last person I want reviewing code is someone who wants to apply this principle (I don't so much care if they think this while writing code, if and only if it has no tangible downsides in what they produce.)
This is compounded with the following sentences "Beauty often embodies many useful properties. Code that pleases the eye is often readable, idiomatic, and expressive", as if pursuit of this undefined beauty causes these outcomes.
I am not sympathetic to arguments that this is true "in a sense", as this just adds subjectivity and circumlocution to an issue that should be, like good code itself, as straightforward and to-the-point as is possible while getting the job done.
Almost everyone agrees with all or most his design rules. I can agree all day but that doesn't mean I can execute my designs anywhere near as well as he did during his career.
> 2. Good software is useful
The UNIX philosophy highly prioritizes simplicity (number 10 on this list), and there's always been a large group (and still is) of programmers that interpret this as "sacrifice functionality for the purposes of simplicity".