Do something different for a week
blog.sidebits.tech
Do something different for a week
1–10 of 21 posts
Re: Do something different for a week
#2> Implement twice; pick the better version.
This! I like most of the ideas and it sounds like a fun exercise to try a few for 1-2 weeks, but I think that implementing something twice could yield so much value!
In my role I prioritize code maintenance, probably because I hate work with painful codebases, probably because I’ve seen 5 years+millions of dollar projects fail as the tech debt piles up and the codebase grows too fragile to implement new features needed to go to market, probably because I’m lazy and don’t like to read much to know what the code is doing.
But one of the best architectures I’ve ever built was one that I had to implement 3 times. Now, this wasn’t because of my vast wisdom but because I literally coded myself in a corner the first two! (Go rigidity around circular dependencies is a double edged sword)
Re: Do something different for a week
#3I find I take some of these meta-approaches in my own code work but it’s a nice article to spell them out so explicitly.
Re: Do something different for a week
#4I almost have to always draw everything before building it.
I sort out thoughts, see relationships and plan naming and params ahead of time.
Re: Do something different for a week
#5How do you manage consistency with these experiments?
If I do 5 of these micro experiments in a year, do I have 10 weeks of code that idiomatically doesn’t match the rest of the codebase?
Re: Do something different for a week
#6> Implement twice; pick the better version. This! I like most of the ideas and it sounds like a fun exercise to try a few for 1-2 weeks, but I think that implementing something twice could yield so much value! In my role I prioritize code maintenance, probably because I hate work with painful codebases, probably because I’ve seen 5 years+millions of dollar projects fail as the tech debt piles up and the codebase grow…
Mythical Man Month: Build one to throw away
https://wiki.c2.com/?PlanToThrowOneAway or for iphone users https://archive.md/zdfXh (no idea why they are blocking iphone)
Quotes about Joe Armstrong say he solved the same problem in multiple iterations to refine the solution.
Some of his opinions: https://joearms.github.io/published/2014-02-07-why-programmi...
Re: Do something different for a week
#7How do you manage consistency with these experiments? If I do 5 of these micro experiments in a year, do I have 10 weeks of code that idiomatically doesn’t match the rest of the codebase?
They do mention that it probably should not be applied to production code bases. I imagine it's intended to avoid that situation.
> Some of these should probably not be tried for the first time in a professional context where you work with other people in the same code repository, while others can. Use your judgment.
I could see the testing example still being of use in a prod code base though. If you find a useful technique and make useful tests, you can keep them. If they're not, remove them at the end of the experiment.
Re: Do something different for a week
#8Sounds like this guy just needs to finish what he is doing and stop. instead of devising new ways to dick around inside the sandbox.
Re: Do something different for a week
#9how about do nothing. u are perfect already!
Re: Do something different for a week
#10> Implement twice; pick the better version. This! I like most of the ideas and it sounds like a fun exercise to try a few for 1-2 weeks, but I think that implementing something twice could yield so much value! In my role I prioritize code maintenance, probably because I hate work with painful codebases, probably because I’ve seen 5 years+millions of dollar projects fail as the tech debt piles up and the codebase grow…
I’ll frequently do this when I start large refactors or implementations. I’ll build a big ugly branch that kind of works, then, when I have a better idea of where I’m headed, start from master again, building a chain of sometimes a dozen or more PRs, mostly from scratch, that build to the same point as that big ugly branch. Along the way, the code and architecture tend to improve dramatically.