This changes the game for me. Well done.
Dieter Rams' design principles applied to software engineering
41–50 of 63 posts
Re: Dieter Rams' design principles applied to software engineering
#42Earlier quoted context omitted.
Question. Are those people scorning you because you are thorough down to details, or because you are thorough down to details _at the cost of something else_?
Mostly because they assume that it's at the cost of schedule. 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…
You sound like a good person to learn from. Do you have any video tutorials about your process (how you go about building complex applications in such a short time, what you prioritize, how you plan your work days etc.). I am also curious about the resources you used to build up your developer & project management skills.
Re: Dieter Rams' design principles applied to software engineering
#43Earlier quoted context omitted.
> Mostly because they assume that it's at the cost of schedule. How can you change that assumption?
The only way is the way that I've been forced to work, my entire life. 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 h…
Thanks for that context. I am still curious - How can you change what other people assume that you think is not correct?
Re: Dieter Rams' design principles applied to software engineering
#44Prepares to be downvoted... 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 alw…
[deleted]
Re: Dieter Rams' design principles applied to software engineering
#45If I follow this it would take me 9 months to build a signup form.
The real question is how long the next login form after that would take you. A day?
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.
Re: Dieter Rams' design principles applied to software engineering
#46Earlier quoted context omitted.
The only way is the way that I've been forced to work, my entire life. 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 h…
Thanks for that context. I am still curious - How can you change what other people assume that you think is not correct?
I guess I don't understand the question.
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.
Re: Dieter Rams' design principles applied to software engineering
#47This submission broke the rules for "Show HN" - this is reading material, not a project people can try out and play with. We've taken "Show HN" out of the title now.
Re: Dieter Rams' design principles applied to software engineering
#48Seems to be mixing up software with code . > 3. Good software is aesthetic > > Take a moment to step back and look at your code. > It should look beautiful to you. > ... It's not that the code quality doesn't matter, but this is just apples to oranges.
I'd go even further and say code is pretty strictly a liability. 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. Why else would we encourage things like loose coupling and building upon abstractions? That thing you're abstracting away is likely to be thrown away at some point and replaced with something different. I can understand fee…
While I think the core of your idea is right, some could understand it the wrong way:
> 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.
Re: Dieter Rams' design principles applied to software engineering
#49Prepares to be downvoted... 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 alw…
A lot of people don't (really) seem to agree with number two here:
> 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".
Re: Dieter Rams' design principles applied to software engineering
#50Funny! I wrote the same article 6 years ago: https://www.dein.fr/2015-10-01-10-principles-for-good-code.h...
> Companies that stay successful are the ones which don’t fear to constantly disrupt themselves through technological innovation. 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 efficie…
Good poker players don't exactly play it safe. They play very cautiously most of the time, but very aggressively when the odds are in their favor. And sometimes they bluff on top of that.