Fight for Pareto’s law, look for the 20% of effort that will give you the 80% of results.
Perfect is enemy of good, first do it, then do it right, then do it better.
It’s either worth doing right or not worth doing at all.
I don’t identify with this manifesto, it feels more like something written for startup cowboys slinging code out than people wanting to write minimal, clean code.
Here is my take on a minimalist software engineer manifesto.
Keep it correct - measure twice, code once
Keep it simple - aim to solve a single task well
Keep it secure - only allow things required to perform your task
Keep it documented - your tool is useless, if no one knows how to use it
When something isn’t already a solved problem, being able to identify potential correctness pitfalls depends upon having a functional implementation. In other words: write a prototype and throw it away (i.e., first do it and then do it right).
Of course, most code written for businesses isn’t actually original or solving original problems – the ‘prototype’ is somebody else’s implementation, written years before.
Sure. This is engineering 101. Build a model in scale.
However the way this manifest is written it sounds like he would like to build a bridge then patch it up when cracks start to show up while people start driving through it - that is not a prototype and that is not engineering.
About half the crustaceans are interpreting this manifesto the way you are, and about half are interpreting it the way I am, which probably means it’s poorly written!
I’ve got a tendency to steelman essays like this, so it’s absolutely possible that this guy is actually defending cowboy coding, but that’s absolutely not how I read it.
The worst code you’ve ever written is the code that is no longer used. Is called YAGNI (You Are Not Gonna Need It).
I’ve always known YAGNI to refer to something worse than that, code you never need in the first place. Code that was written to be “flexible” and “generic” such that it could be used in as many different situations as possible, but in making it generic the implementation gets so complicated that when the original need changes slightly in a way not originally anticipated its massively more work to go in and make changes. The idea is that you keep it simple and in the future when you need something different you’ll spend less time changing it than you would have making it generic in the first place.
I’m rather familiar with this problem in the codebase I’m working on at work.
I clicked on one of the topics at the top, the page scroll to the topic in question, but I couldn’t use the back button to go back up. How about <a href="#fight-for-patero">?
While I appreciate the sentiment, does Pareto’s law actually apply here? The concept has been used and abused more times than I can count. Maybe the truth is, different projects have different poi ts at which added dude functionality is the exponential driver of cost?
Yeah, I feel like people abuse the Pareto principle to describe basically any exponential distribution. To be honest, I have a lot of problems with the specific terminology the author uses throughout this manifesto. (I posted it because I like the general thrust, and because particular points are non-obvious.)
if you can get past the shiny distraction of criticizing whatever web library the author used, this article is chock full of good advice that will make you more productive. i had to learn most of these lessons the hard way, and i love reading an article that makes me think, “i don’t have to write this article anymore, someone has done it better.”
What distinguishes a “Minimalist” software engineer from a non-minimalist one?
This manifesto seems to talk generic stuff which could as well be applied to an enterprise waterfall software engineer. I kind of assume here that Enterprise and Waterfall are buzzwords considered to be the anti-thesis of Minimalism, isn’t it?
It’s either worth doing right or not worth doing at all.
I don’t identify with this manifesto, it feels more like something written for startup cowboys slinging code out than people wanting to write minimal, clean code.
Here is my take on a minimalist software engineer manifesto.
When something isn’t already a solved problem, being able to identify potential correctness pitfalls depends upon having a functional implementation. In other words: write a prototype and throw it away (i.e., first do it and then do it right).
Of course, most code written for businesses isn’t actually original or solving original problems – the ‘prototype’ is somebody else’s implementation, written years before.
Sure. This is engineering 101. Build a model in scale.
However the way this manifest is written it sounds like he would like to build a bridge then patch it up when cracks start to show up while people start driving through it - that is not a prototype and that is not engineering.
About half the crustaceans are interpreting this manifesto the way you are, and about half are interpreting it the way I am, which probably means it’s poorly written!
I’ve got a tendency to steelman essays like this, so it’s absolutely possible that this guy is actually defending cowboy coding, but that’s absolutely not how I read it.
I’ve always known YAGNI to refer to something worse than that, code you never need in the first place. Code that was written to be “flexible” and “generic” such that it could be used in as many different situations as possible, but in making it generic the implementation gets so complicated that when the original need changes slightly in a way not originally anticipated its massively more work to go in and make changes. The idea is that you keep it simple and in the future when you need something different you’ll spend less time changing it than you would have making it generic in the first place.
I’m rather familiar with this problem in the codebase I’m working on at work.
Interesting, though I expected a manifesto for minimalists to be more minimal. :)
1.4MB for a minimal manifesto page :) LOL!
That manifesto needs to follow this manifesto: http://brandon.invergo.net/news/2013-03-10-Anti-web-design-Manifesto.html
I clicked on one of the topics at the top, the page scroll to the topic in question, but I couldn’t use the back button to go back up. How about
<a href="#fight-for-patero">?While I appreciate the sentiment, does Pareto’s law actually apply here? The concept has been used and abused more times than I can count. Maybe the truth is, different projects have different poi ts at which added dude functionality is the exponential driver of cost?
Yeah, I feel like people abuse the Pareto principle to describe basically any exponential distribution. To be honest, I have a lot of problems with the specific terminology the author uses throughout this manifesto. (I posted it because I like the general thrust, and because particular points are non-obvious.)
if you can get past the shiny distraction of criticizing whatever web library the author used, this article is chock full of good advice that will make you more productive. i had to learn most of these lessons the hard way, and i love reading an article that makes me think, “i don’t have to write this article anymore, someone has done it better.”
Quibble: it’s actually You Ain’t Gonna Need It
What distinguishes a “Minimalist” software engineer from a non-minimalist one?
This manifesto seems to talk generic stuff which could as well be applied to an enterprise waterfall software engineer. I kind of assume here that Enterprise and Waterfall are buzzwords considered to be the anti-thesis of Minimalism, isn’t it?
Indeed, most of the manifesto are just platitudes.
I like this talk about destroying software more than I like this manifesto.
ajax.googleapis.com
fonts.googleapis.com