No post body was provided.
My guiding principles after 20 years of programming (2020)
101–110 of 193 posts
Re: My guiding principles after 20 years of programming (2020)
#102That's a great list!
I feel like he "gets it."
#10 is my fave:
> When making decisions about the solution all things equal, go for this priority: Security > Reliability > Usability (Accessibility & UX) > Maintainability > Simplicity (Developer experience/DX) > Brevity (code length) > Finance > Performance But don’t follow that blindly because it is dependent on the nature of the product. Like any career, the more experience you earn, the more you can find the right balance for each given situation. For example, when designing a game engine, performance has the highest priority, but when creating a banking app, security is the most important factor.
I would add "Localizability," just before "Usability."
In my experience, security and localizability need to be integrated from the very first line of code. They can't be added after the fact.
Re: My guiding principles after 20 years of programming (2020)
#103Here's one more from me: count your liabilities. 1. Code is a liability. No code? No bugs. The best commit is one that removes unnecessary code. This includes dependencies. 2. State is a liability. Multipliers for: hidden or non-obvious state, shared state, externally (by actors you don't control) accessible state, concurrently accessed/mutated state. Often the worst offenders are environment settings/configuration,…
> E.g.: maybe don't output results reliant on a HashSet order - sort them. I would much prefer shuffling them in that case. Less expensive and reduces the size of the public API. (Returning items in a specific order, whichever it is, still is a sort of promise.)
One gotcha is that some SQL databases automatically sort items when you do a GROUP BY.
Then a few releases later the database switches from a B-tree to a hashmap for the GROUP BY internals and now your output is no longer sorted.
Re: My guiding principles after 20 years of programming (2020)
#104> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…
me too...
I usually so a vertical proof of concept where I tackle each step I understand in a unit-test. ofc it's no unit test- the test framework just serves as an quick entry point where I can test different approaches next to each other or different versions/variants of each approach.
like a repl with the benefit of an easy view of my "history" with the ability to step back in time.
Re: My guiding principles after 20 years of programming (2020)
#105Earlier quoted context omitted.
> I believe people underestimate the power of a good IDE. Definitely. And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. Which, sure, vim is great! And you can get a lot of decent plugins that can make that workable. But gosh IDEs provide so much powerful functionality, why would you make your life harder on purpose by not using them.…
> And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. I share the sentiment, but for completely other reasons. Human mind is very limited - it can only hold so much complexity at once before it starts making mistakes and oversights. IDE's raise that bar of tolerable complexity, making it easier for people to build enterprise-level Rube…
> Of course, sometimes we have no choice but to meet the deadline
What do you mean, "sometimes"?
Re: My guiding principles after 20 years of programming (2020)
#106Earlier quoted context omitted.
> I believe people underestimate the power of a good IDE. Definitely. And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. Which, sure, vim is great! And you can get a lot of decent plugins that can make that workable. But gosh IDEs provide so much powerful functionality, why would you make your life harder on purpose by not using them.…
> And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. I share the sentiment, but for completely other reasons. Human mind is very limited - it can only hold so much complexity at once before it starts making mistakes and oversights. IDE's raise that bar of tolerable complexity, making it easier for people to build enterprise-level Rube…
I've approached IDEs similarly. But in addition to this, a lot of IDEs lack real accessibility functionality. Jetbrains has accessibility features [0], but it is clear no one at Jetbrains actually uses them. This isn't unique to Jetbrains, there are a lot of companies that implement what I call "fake accessibility". There's a section in their settings to enable "accessibility", but if you actually use it and depend upon it you're met with a garbled mess.
> For macOS, switch on the VoiceOver and install and set up IntelliJ IDEA. However, for a full screen readers' support, we recommend Windows.
I've never tried the Windows version, but the VoiceOver version is unusable.
[0]: https://www.jetbrains.com/help/idea/accessibility.html#scree...
Re: My guiding principles after 20 years of programming (2020)
#107> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…
That's not coding the solution though, that's exploring the problem.
Obviously it's helpful to formalize the problem! This is no different from manipulating mathematical equations on a piece of paper. =)
Re: My guiding principles after 20 years of programming (2020)
#108> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover ed…
Yeah, it could just be me, but I prefer to make two false starts, toss them, and then get it right on the third attempt rather than attempting to whiteboard the problem for two weeks. Not only is it more interesting to me to try three different ways to tackle a problem, but I have been burned when the two weeks of whiteboarding missed something and I'm back to having to iterate anyway. To be sure, I do a little white…
I forget where I read this, but something like:
first time to understand the problem
second time to understand the solution
third time to do it right
Re: My guiding principles after 20 years of programming (2020)
#109Earlier quoted context omitted.
To be the devil's advocate, you wouldn't want to pay your plumber for time on his pet project while he's working on your bathroom.
Given the choice, I would absolutely go for the plumber that spends some of their time practising difficult plumbing jobs and doesn't just do routine cases. Even if they are 15 % more expensive. I honestly believe they'll be much better equipped to handle anomalies, should they occur.
Looking at it further, I would ignore a 15% difference if it came with any enticing reasonable. Any small difference in quality is certain to return me much more than 15%.
Re: My guiding principles after 20 years of programming (2020)
#110> Bugs take shelter in complexity. “Magic” is fine in my dependency but not in my code. I disagree with this. Dependencies become your code and any magic will always come and bite you, no matter if it's written by you or a downstream dependency. The guiding principle should be: Reject magic at all cost
I disagree. For a huge majority of projects and teams, it is infeasible to build everything in-house. The way I see it, you can either 1. take an extremely impractical amount of time reinventing the wheel in house, or 2. take a (IMO a relatively much smaller) hit when you fail to take the 10 minutes to read the breaking changes on the dependency. Read this, make fixes, and everything is working again. If you hit a ma…
My point is take dependencies, just skip the magic ones because they are vile