5 ms·
I get that but I couldn't be more different: I love greenfield projects. I find designing a robust, performant and reliable architecture to be the most interest
by chefandy 3y ago
I get that but I couldn't be more different: I love greenfield projects. I find designing a robust, performant and reliable architecture to be the most interesting part of the process.
- wouldbecouldbe 3y agoYeah same here. Much more fun than patching other people (or your own) work. But different personalities, gross of the proffesional pro work is not greendfield sadly!
- chefandy 3y agoYeah. I do love a good bug hunt or an adrenaline spiking incident response (though I've never been traumatized with any real disasters) but I get "fresh SimCity map" feels starting something new.
- chefandy 3y ago(Though I suppose people who don't like greenfield projects probably don't like fresh SimCity maps, either!)
- marklubi 3y agoI too love greenfield projects. It's so satisfying to build something amazing from scratch.
- sph 3y agoI have to port an app I've written in Rust to Elixir. [1] It is Sunday and I have to force myself not to open Emacs today. That's the best of both worlds: a reimplementation of an existing project. You have all the freedom of a greenfield project, and you don't suffer from the "blank page syndrome" or writer's block the author talks about. Port the tests over, then rewrite everything, this time with a better architecture. [2] -- 1: Since someone is bound to ask, I am incorporating a Rust standalone app into a larger Elixir monolith. Because while static typing is nice, turning a Rust app into a highly-concurrent and highly resilient with native OS primitive (threads & co.) or, yikes, async, is masochistic when I have the power of the BEAM at my disposal. 2: Tongue-in-cheek here, I am well aware of https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- sodapopcan 3y agoI'm currently working on a greenfield project that is a rewrite of a smaller portion of a larger app I worked on several years ago. Normally I wouldn't advocate for a rewrite, but the business has since been re-imagined and vastly simplified. Incidentally, I'm also doing it in Elixir. Not only do you not suffer from the "blank page", you can are privy to all the mistakes made before. Of course, you're now open to make a bunch of new mistakes, but that's ok—there's still the benefit of tons of knowledge from the original project. Furthermore, the Elixir ecosystem really helps mitigate that "too many tools" feeling.
- benzible 3y agoI've done a lot of greenfield web application projects and my current stack of choice is also Elixir / Phoenix / LiveView. An opinionated stack solves a lot of the issues the author mentions. He also seems to be mixing in product / UX concerns with implementation concerns.
- sodapopcan 3y agoIt does make life so much easier. My whole stack is Elixir, Postgres, a bit of Vanilla JS, Tailwind (which isn’t strictly needed but I love it), and libvips (we do lots of stuff with images). Esbuild is in the mix for assets but no npm! And no web API!
- sph 3y agoSame stack here, I just use Stimulus instead of Vanilla JS because it pairs well with Live View, it is sane and simple. Put everything in a container, stick it in a dedicated server at Hetzner, and Bob's your uncle.
- sodapopcan 3y agoI gotta look into Hetzner. Their servers are in the EU no? Or are they viable for an NA app? I know I can google this stuff but just interested in your high level experience since you have the same stack.
- stavros 3y agoAgreed, and it doesn't even feel overwhelming to choose between all these options. It's just fun.
- GuB-42 3y agoI used to think like this, but as I worked on so many messy projects, I changed my mind. Designing a robust/performant/reliable architecture right from the start is not "interesting", it is effectively impossible unless you have divination skills. At some point, your architecture will suck, and restarting from scratch is usually a bad idea, and that's when things get interesting. That is, fixing the mess you created, making something robust/performant/reliable out of something that is not, with the additional constraint of not breaking it in the process. But you still need to start somewhere, even you know it will fail. It means you will essentially do a dice roll and hope for the best. Yes, the beautiful architecture you start with is nothing more than that. If you leave after that, not only it may not be cool for the ones who will inherit your mess, but you also won't get to see the hard (and interesting) part. Of course, even though it will always be a dice roll, it doesn't mean your initial decisions won't matter. How fast will you fail? (failing fast is a good thing) How fixable your mess is? How will it fair after an army of monkeys tramples over the code? etc... These are questions experience can help you answer, but you won't get this experience by doing greenfield projects. You will get this experience by being in front of the fan as shit hits it. So yeah, I understand the love for greenfield project. It is like a reprieve, where you can use that experience acquired during the time you were covered in shit, and try to make the best roll. To me, it is the comfort zone, but as often, the comfort zone is not the most interesting.
- chefandy 3y agoEh, I've got 20 years in tech under my belt and I'm totally comfortable with everything I do being temporal. I'm not talking about NASA reliable-- I dont work on stuff where downtime=dead people, so that's a big caveat-- I'm talking about day-to-day manageable for the length of its useful life. It can be good without being perfect forever. It can even be perfect for a little while and good enough for a long while and still be worth it.
- majormajor 3y ago> I get that but I couldn't be more different: I love greenfield projects. I find designing a robust, performant and reliable architecture to be the most interesting part of the process. If you're working on a greenfield project there's a very high chance that your "robust, performant and reliable" is someone else's tech debt once people need different things from the system in a few years... And then the more clever that original work, the harder the rework.