4 ms·
I feel like sometimes it’s a form of procrastination. There are things we don’t want to do (talk to costumers, investors, legal, etc.), so instead we do the fu
by brap 11mo ago
I feel like sometimes it’s a form of procrastination.
There are things we don’t want to do (talk to costumers, investors, legal, etc.), so instead we do the fun things (fun for engineers).
It’s a convenient arrangement because we can easily convince ourselves and others that we’re actually being productive (we’re not, we’re just spinning wheels).
- marfmarkus 11mo agoIt's the natural evolution to becoming a fun addict. Unless you actively push yourself to do the uncomfortable work every day, you will always slowly deteriorate and you will run into huge issues in the future that could've been avoided. And that doesn't just apply to software.
- ErroneousBosh 11mo agoYou know what, you're right. I should get off HN, close the editor where I'm dicking about with HTMX, and actually close some fucking tickets today. Right after I make another pot of coffee. ... No. Now. Two tickets, then coffee. Thank you for the kick up the arse.
- moritzwarhier 11mo agoI see your point. But accidental complexity is the most uncomfortable work there is to me. Do programmers really find so much fun in creating accidental complexity? Removing it, no matter whether I created it myself, sure, that can be a hard problem. I've certainly been guilty creating accidental complexity as a form of procrastrination I guess. But building a microservices architecture is not one of these cases. FWIW, the alternative stack presented here for small web sites/apps seems infinitely more fun. Immediate feedback, easy to create something visible and change things, etc. Ironically, it could also lead to complexity when in reality, there is (for example) an actual need for a message queue. But setting up such stuff without a need sounds easier to avoid to me than, for example, overgeneralizing some code to handle more cases than the relevant ones. When I feel there are customer or company requirements that I can't fulfill properly, but I should, that's a hard problem for me. Or when I feel unable to clarify achievable goals and communicate productively. But procrastrination via accidental complexity is mostly the opposite of fun to me. It all comes back when trying to solve real problems and spending work time solving these problems is more fun than working on homemade problems. Doing work that I am able to complete and achieving tangible results is more fun than getting tangled in a mess of unneeded complexity. I don't see how this is fun for engineers, maybe I'm not an engineer then. Over-generalization, setting wrong priorities, that I can understand. But setting up complex infra or a microservices architecture where it's unneeded, that doesn't seem fun to me at all :)
- whstl 11mo agoI 100% agree. Normally the impetus to overcomplicate ends before devs become experienced enough to be able to even do such complex infra by themselves. It often manifests as complex code only. Overengineered infra doesn't happen in a vacuum. There is always support from the entire company.
- arethuza 11mo ago"Do programmers really find so much fun in creating accidental complexity?" I certainly did for a number of years - I just had the luck that the cool things I happened to pick on in the early/mid 1990s turned out to be quite important (Web '92, Java '94). Now my views have flipped almost completely the other way - technology as a means of delivering value. Edit: Other cool technology that I loved like Common Lisp & CLOS, NeWS and PostScript turned out to be less useful...
- moritzwarhier 11mo agoI see what you mean, sometimes "accidental complexity" can also be a form of getting to know a technology really well and that can be useful and still fun. Kudos for that :)
- arethuza 11mo agoOh yes I loved building stuff with all these technologies mostly for my own entertainment - fortunately I was in academia so could indulge myself. ;-)
- tempodox 11mo ago> Do programmers really find so much fun in creating accidental complexity? I believe only bad (inexperienced) programmers do.
- SilverSlash 11mo agoI like your idea of doing some amount of uncomfortable work every day, internalizing it until it becomes second nature. Any tips on how to start? (other than just do it) :)
- ChrisMarshallNY 11mo ago> a fun addict Interesting term. Probably pretty on-point. I’ve been shipping (as opposed to just “writing”) software for almost my entire adult life. In my experience, there’s a lot of “not fun” stuff involved in shipping.
- whstl 11mo agoIs it really for "fun"? Or is it to satisfy the ideals of some CTO/VPE disconnected from the real world that wants architecture to be done a certain way? I still remember doing systems design interviews a few years ago when microservices were in vogue, and my routine was probing if they were ok with a simpler monolith or if they wanted to go crazy on cloud-native, serverless and microservices shizzle. It did backfire once on a cloud infrastructure company that had "microservices" plastered in their marketing, even though the people interviewing me actually hated it. They offered me an IC position (which I told them to fuck off), because they really hated how I did the exercise with microservices. Before that, it almost backfired when I initially offered a monolith for a (unbeknownst to me) microservice-heavy company. Luckily I managed to read the room and pivot to microservice during the 1h systems design exercise. EDIT: Point is, people in positions of power have very clear expectations/preferences of what they want, and it's not fun burning political capital to go against those preferences.
- Treegarden 11mo agoI dont quite follow. I understand mono vs micro services, and in the last 3 weeks I had to study for system design and do the interviews to get offers. Its a tradeoff, and the system design interview is meant to see if one understands how systems can scale to hypothetical (maybe unrealistic) high loads. In this context the only reason for a microservice is independent scaling and with that also fault tolerance if an unimportant service goes down. But its really the independent scaling. One would clearly say that a monolith is good for the start because it offer simplicity or low complexity but it doesn't scale well to the hypothetical of mega scale.
- whstl 11mo agoThe point is that it doesn't matter which is better or worse for the case, or if you know the pros/cons of each: In those interviews (and in real work too) people still want you skewing towards certain answers. They wanna see you draw their pet architecture. And it's the same thing in the workplace.
- 11mo ago
- ratsimihah 11mo agoMy first 5 years or so of solo bootstrapping were this. Then you learn that if you want to make money you have to prioritise the right things and not the fun things.
- arbol 11mo agoI'm at this stage. We have a good product with a solid architecture but only a few paying clients due to a complete lack of marketing. So I'm now doing the unfun things!
- saulpw 11mo agoIf you have had zero marketing, how do you know what you have is a good product?
- arbol 11mo agoBecause we have a few paying clients who seem pretty happy. We have upsold to some clients and have a couple more leads in the pipeline. We are good at stopping bots and we have managed to block most solvers, which puts us (temporarily) ahead of some very big players in the bot mitigation sector. If we can do this with nearly zero marketing, it stands to reason that some well thought out marketing would probably work.
- ExpertAdvisor01 11mo agoNot really . Even Cloudflares free bot detection is better .
- feketegy 11mo agoIt's also virtue signaling of what a great engineer they are. Have you wired together ABC with XYZ? No? Well I did... blah blah blah