171–180 of 193 posts
It's amazing how this POV lives on, even in an essay which decries technical debt. Documentation and well-written code fill different roles with only some overlap. Your code can be beautifully written, but if I need to read the whole 500+ lines to figure out what you're doing, rather than read a single paragraph at the top of the file, you've burned through a lot of my time. Good documentation explains the why, code explains the how.
If something feels wrong to you that means it is almost certainly wrong. There are so many things I’ve seen that made me go “hmmm, that’s odd”, which I ignored to my peril. An assert that doesn’t quite make sense. An argument type that feels too specific. A hang in ssh once in a while. 7 times out of 11 they’ll turn out later to be the first sign of an error you wish you’d looked into sooner. I guarantee it, 82%.
I've often thought about what interesting findings you would get back if time and people were infinite and all those little things you thought, 'huh? thats weird' and put it in a queue somewhere and a few days later it had been thoroughly investigated and findings documented by some smart person. I'd expect you'd find some weird networking problems for why ssh hangs sometimes, misconfigurations, waste, security vulns etc. So many things we skip over day to day bc it would be a distraction.
Listing Performance as the lowest value bugs me. I understand that most software isn't performance-critical, you can probably afford to use a garbage collected language for most use-cases. But putting performance last contradicts the high priority of Usability in the list, because Usability strongly depends on performance. Your product might still work if it has a second of lag after every operation, but I won't want…
Valuing performance has indirect effects on other things: you're forced towards better models, better SQL queries and better validation/verification of data.
"Pick the right tool for the job" --- exit
> 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…
One: coding is a way to play around with ideas, equivalent to a back of the napkin calculation, a diagram in the sand or a pencil sketch of a part. We use code in this scenario more as a way to write down our thoughts and process. But rather than writing in just pure English and writing an essay or a set of Todos, we write more detailed "specs". "Do this three times or until this value is zero" is also written in code and perfectly understandable in code too.
Two: code is used to run by a computer to produce an outcome. In this case, the back of the napkin sketch IS the part but more thought out.
Society is so used to there being two material objects between the "plan" and the"final product" that we forget that code is different. With code, the plan and the final product are of the same form. Of the same physical space.
Earlier quoted context omitted.
I take the original text as "don't just jump into coding right away" which I've seen so many people do. As you said, take a little bit to process and think through it, then start out your pseudocode, etc.
You shouldn't try to code a complete top-down solution without fully understanding the problem. (And how often do you fully understand the problem, or think that you do but don't?) But you can code up a bottom-up partial solution of the parts of the problem that you do fully understand, and in the process learn enough to make progress on the total solution, so long as the components you develop in the bottom-up proce…
If I did all the beginnings first, I'd then go back to doing the middle of A and realize I did the beginning wrong and have to go back to fix the beginnings of B and C.
Earlier quoted context omitted.
Here’s a fun little story that’s stuck with me for years because it demonstrates this in a very hacker way. (Forgive the lack of specificities, I tell this as a parable) A fancy new office tower was opening downtown. Around this time, office space was at a premium so they soon sold out all their floorspace, and the project was considered quite successful except for one small problem; the architect seems to have insta…
Fake progress bar?
For example: > Deprecate yourself. ... Don't own the code.
On one hand, this is true: ultimately, you want the code to be independent of you. But on the other hand, I've witnessed bad code quality proliferate in a repo many times because no one is taking ownership of the code they write: they just write enough to finish the task and move on. And it rarely gets caught in code reviews either because all the other members are operating in the same mindset too. His principle misses this side of the coin.
Over the years, I came to realize that at least for me, there is one root force behind almost everything for me, including how I code, how I interact with members, etc. It is: responsibility. I am simply trying my best to write responsible code, create a responsible product, be responsible to my team members and colleagues, etc. The rest of the stuff (like what you might call 'principles') are just specific manifestations of this feeling. e.g. code ownership: I need to own my code to the extent that I need to be responsible for my work, but on the other hand, it is also my responsibility to ensure the code does not depend on me forever. Albeit this probably may be too abstract to call a principle. In that case, I'd rather not have any.
Earlier quoted context omitted.
Well, I am a vim user, and I deride noone for the tools they want to use. If someone wants to work in a super-modern IDE, great. If someone wants to work in Notepad++ great. If someone wants to work in ed and use a lineprinter, great. If someone wants to use EMACS, great. Programming is one of the professions, where the craftman gets to choose the tools, and for me, that is something to celebrate. So with that being…
> If someone wants to work in ed and use a lineprinter, great. Sure, as long as it's not on my dime! :-) vim et al are great and I know skilled users can get very productive in them, but I would not push it as a default environment for incoming developers. The amount of force-multiplying functionality in the stock install of IntelliJ or VSCode is very good.
I would not push any default environment on incoming developers unless there is a very good reason to do so (eg. custom graphical lowcode tool that only works with a specialized editor). As I said, one of the beautiful things about programming is that the craftman gets to chose the tools.