51–60 of 193 posts
In other words: I'd be wary of sticking to these unless they fit who you are and the conditions in which you operate at your best.
> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. I agree with a lot of the points made by the author (2, 5, 7, and 8 re…
With big projects spanning across years, the "problem" is often a moving target. Adding new features alters the problem space dynamically. The best you can do as a maintainer is to be mindful of the original problem that the solution was architected for, and extend the thing without crossing certain boundaries and assumptions.
> 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…
> Any function that’s not pure should be a class. Any code construct that has a different function, should have a different name. I definitely haven't been following this... anybody else using nearly 99% of functions in their frontend work? (Typically I'm in the React TypeScript world)
Any function that’s not pure should be a ~class~ component.
ie, when you have a bunch of functions that operate on the same kind of struct/set of state, and in fact you want to prevent other functions from messing with it (you want to make it internal), you group them in some way. The OO word for that is a class. React is a component; which are much more composable because we ditched the stricter concept of inheritance of OO classes.
Hell, the es6 class system is really just syntactic sugar around Brendan Eich’s nifty prototypal system. If it weren’t for the weak typing and lack of std.lib, JavaScript would be an amazing language.
…which is to say it would probably be Go haha
That means you'll always be stuck doing things using existing paradigms. Which is fine if you're only developing an application, but not fine if you want to effect more fundamental change.
> Never start coding (making a solution) unless you fully understand the problem
Sometimes, I cannot understand the problem until I've started coding.
> Tech debt is like fast food.
Yes, in the sense that where I work, many people have it every day :-(
> go for this priority: Security > Reliability > Usability etc.
I don't buy that gradation.
> Don’t use dependencies
Contradicts a bunch of other points IMHO.
> Any function that’s not pure should be a class.
No. Verbs are not nouns. But - if he means functions with static variables, then maybe.
> Software is more fun when it’s made together. Build a sustainable community.
Very difficult in my experience. In a commercial setting, the company controls your software, and it's a totalitarian 'community', if at all. With your pet projects, it's often difficult to attract users to participate more actively.
Rule #1: Software is a social service. If you're not writing for the user, but rather for the sake of writing code, you're not a good programmer. Write for the user, whether that user is Joe Sixpack or Jane Hotdev, or even if you are the user - assume the role of servicing the end user. Software is a social service.
Earlier quoted context omitted.
If we're arguing here that it's a great form of professional development, why would it be a joke to get better at your job, on your job?
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.
> 10. 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 In my experience simplicity is the cornerstone priority that nearly all other attributes stem from. Simpler solutions tend to be easier to rationalize/debug, leading to sys…
The other weird one is finance near the bottom. Typical engineering bubble style thinking... make sure your solution actually provides value and that people will pay for it! Otherwise you're wasting your time solving the wrong problem! The importance of that cant be understated!(unless your goal isn't to provide value of course)
> 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…