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".
That is a great mindset IMHO, it makes a huge difference when you pour love into your work.
I also have a lot of writings and whatnot, on my personal site[2].
Frankly, I spend most of my time writing production code, so I don't break off too often, to refresh my blog. I should actually do something, soon. It's been a while since I came up for air.
[0] https://www.tryswift.co/world/
I must say that I wonder how much work you need to put in to get to your desired level of quality. Excuse my bluntness, but would you consider yourself a workaholic? Also, I find it odd that you say you don't make a dime from your work, even if it's mostly FOSS. Surely high quality work should attract high quality rewards.
How can you change that assumption?
I'm a high school dropout with a GED, and some rather spotty tech training.
That means that I have had to fight, claw, and prove myself at every single step. No easy slopes for me. Double-black-diamond, the whole way. Very darwinian. Exhausting.
Fortunately, I don't have to prove myself to anyone, anymore. I am working with a bunch of folks that have known me for years, and are quite aware that I'm "for real." I don't make a dime, and don't really care. I enjoy the work.
Kind of a relief, really.
I can't prevent other people from assuming anything.
I have a portfolio, with complete, start-to-finish repos of many shipped projects. If no one wants to review it, then there's nothing I can do.
I’m definitely somewhat OCD. Not sure that I’m really a “workaholic,” in the destructive sense, as I actually really enjoy doing this stuff, and frequently take breaks to do errands and chill out. I suspect a lot of folks would not find my lifestyle attractive, but it works for me.
I am a bit “on the spectrum,” which makes me an excellent architect and coder, but can cause issues with my interpersonal relationships.
A lot of what looks time-consuming in my code and writing, is actually the level of habit, and just “flows,” without my having to think about it. I write well, and quickly. It has been my experience, that I generally outpace my teammates (break time!).
I’ve been writing all my life, and I come from a fairly well-educated and literate family. My younger brother and I are the “redneck engineers.” Everyone else has Ivy-League sheepskins. My older brothers and sisters have all published books and papers, and whatnot.
As far as rewards go, I would have been happy to work with others. I spent most of my career, on teams. It has been my experience, though, that few people want to work with me, mainly because I'm "chronologically-challenged." Some folks have been quite blunt about it, while most have been fairly weasely.
Others actually don't want to write high-quality product. It's a deliberate decision to embrace mediocrity and "barely tolerable" quality. It may sound ridiculous, but they make money; sometimes, quite a bit. It's hard to argue with results. As long as consumers are willing to pay for poor quality, there will always be a plentiful supply of dross. It can be argued that my development methodology is not cost-effective. I won't lose any sleep over it. I'll do it for free.
Not a big deal. I really enjoy doing what I do, and I don't need anyone else's approval or support, if they aren't willing to give it. It sounds "arrogant" (and I have often been told that I'm "arrogant"), but it's actually just "confident." I don't think I'm God's Gift to Programming, but I know damn well that I am in the upper percentile. I'm aware of quite a few others that are better than me, and I look forward to continuing to learn, and be humbled by the challenges.
I've spent my entire life shipping software. I'm not exaggerating. Here is the first engineering project I ever did[0], [1] (Download PDFs). I architected it, designed the hardware and electronics, wrote the firmware OS, and the host drivers. My very first project was a top-to-bottom hardware/firmware/software design project. It was used in an ATE system for "DC-to-Light Super Bearcat Scanners," made by the company I worked for, back then (they would not be a big deal, these days). That company is long dead.
That same "on the spectrum" thing, means that I also work just fine, alone. I have to greatly reduce the scope of my work, but I can get quite a bit done, all on my lonesome. The project that I'm working on now, is an example. It's the kind of thing that usually is done by a team of engineers.
[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
[1] https://littlegreenviper.com/TF30194/ATE-System-Driver-Manua...
But since you are good at turning ideas into polished products, what about your own ideas? I'm talking about simply creating "catchy" apps and selling them on the App Store. Is there a good living to be made this way, with a skill level like yours? Can you get any predictable/consistent success? I'm guessing no matter how good an app is, you still need a fair bit of luck to get it seen by a lot of people (or perhaps the "right" influencers) to make a hit out of it. And yet when you see something simple and catchy like FlappyBird, made by some seemingly random guy in Vietnam, it seems obvious to everyone other than himself that millions would buy it. I wonder how many nice and catchy little apps like that never catch the big wave, and die after getting downloaded by a handful of people.
I also have a bunch of OSS SPM modules: https://riftvalleysoftware.com/work/open-source-projects/
This one is fun: https://riftvalleysoftware.com/work/open-source-projects/#RV...
It's a very "in your face" UI element. It's the star of the show, and I have a personal philosophy that UI should remain in the background, as much as possible.
This is why waitstaff at restaurants often wear black uniforms.
The checkbox widget[0] has actually been far more useful to me. I use that all over the place (In its SFSymbols form, so it looks like a Mac checkbox). I'm not a fan of Apple's UISwitch widget.
I will, eventually, do SwiftUI versions of these widgets, but I'm not in a hurry.