It’s extremely difficult to be simultaneously concerned with the end-user experience of whatever it is that you’re building and the architecture of the program that delivers that experience. Maybe impossible.
I’m sorry… WHAT? That’s a fallacy, a false dichotomy between solving a problem with ugly code and losing sight of the problem because you want to achieve $PERFECTION (however that looks like for you).
Maybe as a Jr. dev it is hard to understand that’s there more to programming than patterns, and that it’s ok to not follow them religiously, but that’s literally the job of a Sr. developer to not lose sight of the problem while architecting a solution.
I would say, no, do not code like you just learned to program. Programming is easy, writing maintainable code is hard. Writing unmaintainable code on purpose is being a bad colleague to whoever has to maintain that after you, not to mention unprofessional.
I actually sort of agree with this post - or at least, I sympathise very strongly with what I think is the core point - people are so concerned about the practical secondary priorities, that they lock themselves out of being able to implement the primaries.
For example, people often push the idea that you should monetize your hobbies and look to make them a side-gig. And financially that might be a sensible idea, but from a creative side it can be devastating - it leads to you subconsciously rejecting perfectly valid ideas, just because they seem very strongly unmonetizable. It pushes you towards closed thinking, like throwing out the culture-less petri dish. I sometimes wonder how much progress has failed to materialize due to peoples’ dogged pursuit of progress. As the saying goes, the most exciting phrase in science isn’t “eureka!”, but “that’s funny…”. There are plenty of revolutionary ideas that don’t expose any hint of their actual usefulness until well after they’ve been developed - the only way to escape being trapped by such local optima is to actively explore useless-seeming things.
Actually, the core of his comment is this part:
It’s extremely difficult to be simultaneously concerned with the end-user experience of whatever it is that you’re building and the architecture of the program that delivers that experience.
and
I think the only way to pull it off is to simply not care about the latter.
I agree with the former. I disagree with the latter, but frankly that line screams that the author is in the means-to-end tribe (which personally I’m not).
But realistically, I imagine the comment is intended as a generality and a tenet to be used in moderation, not as carte blanch to do stupid things in the name of expediency. Also, it sounds awfully similar to the concept of an MVP. I’ve heard a saying in gamedev that if you can re-use any of the code from your quick MVP/prototype, then you over-engineered it.
Yours is the only charitable take in the whole thread and a wonderful one at that.
The article to me reads as a small kick in the pants. Ship something, the user can’t gawk at the awesome arch for something you didn’t ship. Or, the end user doesn’t care about your engine architecture, ship that demo.
I appreciate that you didn’t pick one of those generalities and then attempt to use that to unravel the whole post. I read too much tech forums, HN, lobsters, Reddit and the performative argumentation almost has me ill. Something about the milieu of the melee kill, online discussion is now combat.
For a lot of code, the requirements of clean architecture and the user requirements are the same because they have the same underlying problem: the requirements will change at least once between the start and end of the project. Separation of model and view don’t exist because people like building pretty abstractions, they exist so that when (not if) you discover that your UI doesn’t meet your users’ needs, you can aggressively modify it without touching most of your code. Ideally, they let you largely decouple design and code, so that experts in human-computer interaction can work on your UI and give you something that you wire to your model.
Several of his blog entries read like this, and I suspect it comes from his background of programming computer games, and part of it just being a contrarian about programming itself. But I find that even if I disagree with what he says, he does get me thinking about it. Unfortunately, he’s no longer updating his blog.
Eh, the way I read it (which may not be in line with what he meant) is to use the easiest too for the job up front, rather than the “most correct”, especially when you’re trying to make a creative/impressive thing. Somethings benefit from grunt work.
And, the role of considering user experience is often separate from the role of arch on many teams.
I have doubts about this. He says he threw something together in half an hour that moved some colors around and called it done, and was blown away when other people did lots of cool things. And he saw the code and those cool things were done really messily in code. His takeaway is that you can do cool things or things with clean code.
I think there are two different problems here.
First, the author was mentally unengaged and threw together something quickly and then felt embarrassed, and so came up with a dichotomy that, “oh, well, because I did something with clean code, I couldn’t think about how to make what I was doing cool.” I’m reminded of Alan Kay recounting E. Power Biggs’s advice to “Play it grand.”
Second, the other kids were producing interesting work, but there was no feedback cycle of looking at it with them and saying, “Okay, you can do this more easily here like this. What kind of cool stuff could you do if you had that additional capability?” Kind of the atelier model in art and architecture.
Yes, producing ambitious work that stretches your technique is going to led you to technical issues which you then have to resolve. That’s the point of the ambitious work. On the other side, when a company hires a senior engineer they’re usually looking for someone who has done that ambitious work and for whom the company’s problems are not particulary ambitious technically.
I have doubts about this. He says he threw something together in half an hour that moved some colors around and called it done, and was blown away when other people did lots of cool things. And he saw the code and those cool things were done really messily in code. His takeaway is that you can do cool things or things with clean code.
Yeah, that’s the big difference. How long did it take them? If he spent the same amount of time as they did, would his demo have been even better?
And also, what would happen if a product manager decided that the skull should be a little taller, slightly to the left and the blood dripping animation should be 30% slower. Oh, and please insert an additional blue skull over here while you’re at it, but that one should wiggle a little. Surely, making small changes like this should take a fraction of the time it took to build the thing from scratch…
unless what you really want to be is a software engineer, and not the designer of an experience.
I think one of the points is that “product manager” is the programmer. The whole thing starts from the idea that they learned to program to make the skull.
I have nothing but respect for that programmer. They wanted to do something and they’ve achieved it through what they knew/could learn. My objection is aimed at the idea that we should still write code like them as professional programmers.
If you’re a skull experience creator you can hire some programmers to execute your vision. Those folks are professional programmers. On the other hand if you as the skull experience creator happen to do the programming as well, the concerns/considerations about adding a “blue skull” etc change. You’re intimately familiar with the requirements and the cost of a requirements change. The product manager never surprises the programmer because they are them.
My objection is aimed at the idea that we should still write code like them as professional programmers
I don’t think this is in conflict with what I quoted. Again if somebody else is deciding where the skull goes you’re clearly not the designer of the experience.
I don’t think most well-traveled architectures are that constraining. Just don’t lose sight of the experience you’re trying to create, and do satisfy that as a top priority. Zoom out from code and focus on the product. That may often mean simple code, but it doesn’t mean foolish code.
I’m sorry… WHAT? That’s a fallacy, a false dichotomy between solving a problem with ugly code and losing sight of the problem because you want to achieve $PERFECTION (however that looks like for you).
Maybe as a Jr. dev it is hard to understand that’s there more to programming than patterns, and that it’s ok to not follow them religiously, but that’s literally the job of a Sr. developer to not lose sight of the problem while architecting a solution.
I would say, no, do not code like you just learned to program. Programming is easy, writing maintainable code is hard. Writing unmaintainable code on purpose is being a bad colleague to whoever has to maintain that after you, not to mention unprofessional.
I actually sort of agree with this post - or at least, I sympathise very strongly with what I think is the core point - people are so concerned about the practical secondary priorities, that they lock themselves out of being able to implement the primaries.
For example, people often push the idea that you should monetize your hobbies and look to make them a side-gig. And financially that might be a sensible idea, but from a creative side it can be devastating - it leads to you subconsciously rejecting perfectly valid ideas, just because they seem very strongly unmonetizable. It pushes you towards closed thinking, like throwing out the culture-less petri dish. I sometimes wonder how much progress has failed to materialize due to peoples’ dogged pursuit of progress. As the saying goes, the most exciting phrase in science isn’t “eureka!”, but “that’s funny…”. There are plenty of revolutionary ideas that don’t expose any hint of their actual usefulness until well after they’ve been developed - the only way to escape being trapped by such local optima is to actively explore useless-seeming things.
Actually, the core of his comment is this part:
and
I agree with the former. I disagree with the latter, but frankly that line screams that the author is in the means-to-end tribe (which personally I’m not).
But realistically, I imagine the comment is intended as a generality and a tenet to be used in moderation, not as carte blanch to do stupid things in the name of expediency. Also, it sounds awfully similar to the concept of an MVP. I’ve heard a saying in gamedev that if you can re-use any of the code from your quick MVP/prototype, then you over-engineered it.
Yours is the only charitable take in the whole thread and a wonderful one at that.
The article to me reads as a small kick in the pants. Ship something, the user can’t gawk at the awesome arch for something you didn’t ship. Or, the end user doesn’t care about your engine architecture, ship that demo.
I appreciate that you didn’t pick one of those generalities and then attempt to use that to unravel the whole post. I read too much tech forums, HN, lobsters, Reddit and the performative argumentation almost has me ill. Something about the milieu of the melee kill, online discussion is now combat.
For a lot of code, the requirements of clean architecture and the user requirements are the same because they have the same underlying problem: the requirements will change at least once between the start and end of the project. Separation of model and view don’t exist because people like building pretty abstractions, they exist so that when (not if) you discover that your UI doesn’t meet your users’ needs, you can aggressively modify it without touching most of your code. Ideally, they let you largely decouple design and code, so that experts in human-computer interaction can work on your UI and give you something that you wire to your model.
This is both good and bad advice. It’s good, you’ll deliver products faster. It’s also bad, none of your friends can help you fix your bugs.
Several of his blog entries read like this, and I suspect it comes from his background of programming computer games, and part of it just being a contrarian about programming itself. But I find that even if I disagree with what he says, he does get me thinking about it. Unfortunately, he’s no longer updating his blog.
Eh, the way I read it (which may not be in line with what he meant) is to use the easiest too for the job up front, rather than the “most correct”, especially when you’re trying to make a creative/impressive thing. Somethings benefit from grunt work.
And, the role of considering user experience is often separate from the role of arch on many teams.
I have doubts about this. He says he threw something together in half an hour that moved some colors around and called it done, and was blown away when other people did lots of cool things. And he saw the code and those cool things were done really messily in code. His takeaway is that you can do cool things or things with clean code.
I think there are two different problems here.
First, the author was mentally unengaged and threw together something quickly and then felt embarrassed, and so came up with a dichotomy that, “oh, well, because I did something with clean code, I couldn’t think about how to make what I was doing cool.” I’m reminded of Alan Kay recounting E. Power Biggs’s advice to “Play it grand.”
Second, the other kids were producing interesting work, but there was no feedback cycle of looking at it with them and saying, “Okay, you can do this more easily here like this. What kind of cool stuff could you do if you had that additional capability?” Kind of the atelier model in art and architecture.
Yes, producing ambitious work that stretches your technique is going to led you to technical issues which you then have to resolve. That’s the point of the ambitious work. On the other side, when a company hires a senior engineer they’re usually looking for someone who has done that ambitious work and for whom the company’s problems are not particulary ambitious technically.
Yeah, that’s the big difference. How long did it take them? If he spent the same amount of time as they did, would his demo have been even better?
And also, what would happen if a product manager decided that the skull should be a little taller, slightly to the left and the blood dripping animation should be 30% slower. Oh, and please insert an additional blue skull over here while you’re at it, but that one should wiggle a little. Surely, making small changes like this should take a fraction of the time it took to build the thing from scratch…
I think one of the points is that “product manager” is the programmer. The whole thing starts from the idea that they learned to program to make the skull.
I have nothing but respect for that programmer. They wanted to do something and they’ve achieved it through what they knew/could learn. My objection is aimed at the idea that we should still write code like them as professional programmers.
If you’re a skull experience creator you can hire some programmers to execute your vision. Those folks are professional programmers. On the other hand if you as the skull experience creator happen to do the programming as well, the concerns/considerations about adding a “blue skull” etc change. You’re intimately familiar with the requirements and the cost of a requirements change. The product manager never surprises the programmer because they are them.
I don’t think this is in conflict with what I quoted. Again if somebody else is deciding where the skull goes you’re clearly not the designer of the experience.
Written in 2010. The year arguably matters, it was a fairly emergent time for startups, particularly mobile apps.
HN Discussion from that time: https://news.ycombinator.com/item?id=2037576
[Comment removed by author]
I don’t think most well-traveled architectures are that constraining. Just don’t lose sight of the experience you’re trying to create, and do satisfy that as a top priority. Zoom out from code and focus on the product. That may often mean simple code, but it doesn’t mean foolish code.