11–20 of 40 posts
The whole "developer-expresso-drinking-JUSTDOIT-positivity" cliche blogpostspam makes my mouth bitter. How many of these queer posts are we going to get on HN? Just-do-it is one of those backwards anachronisms that belongs in the paleolithic pamphlet for success. It sounds good but helps no one.
In addition, once you have hack solutions that are validated by users, replacing them with more robust solutions is extremely satisfying.
I pity the fool who did test first development on applications with less than 10 functionalities for instance.
Even as a manager it's the gaffatape programmers who end up saving the day rather than the best practices.
Obviously I won't advocate against following best practices. It's just that people never seem to agree on what they are, making continuity rather hard to pull off over longer periods of time.
In addition, once you have hack solutions that are validated by users, replacing them with more robust solutions is extremely satisfying.
This is often good advice especially in a startup, but it's not quite absolute. It's worth putting a certain amount of work into maintainability. It's worth pre-empting some classes of issues. And the further you shift into being a mature business, the more serious engineering becomes appropriate.
Yes it's bit of a trade-off, as usual in software. Hacking can be the fastest now, but having worked on 10000loc code which consisted mainly of such hacks and none of the feasible maintainability: your hack might cause a ton of lost time in the future. Then again, the more experienced you get, the easier it will be to spot if a hack is the appropriate thing or not. Like if your software is already nicely established…
It's a concept I try to keep in mind, but am never sure I am "doing it right".
Earlier quoted context omitted.
Yes it's bit of a trade-off, as usual in software. Hacking can be the fastest now, but having worked on 10000loc code which consisted mainly of such hacks and none of the feasible maintainability: your hack might cause a ton of lost time in the future. Then again, the more experienced you get, the easier it will be to spot if a hack is the appropriate thing or not. Like if your software is already nicely established…
Curious if you have some concrete examples of "loosely coupled" software projects. On GH perhaps? It's a concept I try to keep in mind, but am never sure I am "doing it right".
I encountered this in a personal project in the past week. The ideal, normalized schema would be slow and awkward for manual insertions on a daily basis, which I felt would deter me and hence undermine the project. The not-quite-normalized version would be much quicker and more intuitive for me to keep up-to-date, so I talked myself into it. In the future I can always write a stored proc to process the less-normalize…
The coolest thing about ignoring trends is that most of them go away again. I pity the fool who did test first development on applications with less than 10 functionalities for instance. Even as a manager it's the gaffatape programmers who end up saving the day rather than the best practices. Obviously I won't advocate against following best practices. It's just that people never seem to agree on what they are, makin…
The gaffa tape approach encourages further such poorly thought out modifications when the stacks of gaffa become a death trap that you either have to Indiana Jones your way through with a gun, bags of sand and a bullwhip or tear down and rewrite.
I encountered this in a personal project in the past week. The ideal, normalized schema would be slow and awkward for manual insertions on a daily basis, which I felt would deter me and hence undermine the project. The not-quite-normalized version would be much quicker and more intuitive for me to keep up-to-date, so I talked myself into it. In the future I can always write a stored proc to process the less-normalize…
I garden, and before that I tried and failed at bonsai for quite some time. With landscaping it's good to have a five year plan, because everything keeps changing when you're not looking, and if you tried to do everything you wanted all at once you'd hurt yourself and/or kill the plant(s).
I also played Go for a long while, and I found parallels with the philosophies in refactoring. One of the big things in Go is that there are always fifteen things you could be doing but some have contingencies, and among the others you can't win unless you prioritize these options better than the other guy. You know what moves you will make, and when the time is right you will make the move, and the next and the next almost without thinking, because there are patterns just like in software. But right now this other move has more upside so you are doing that instead.