My guiding principles after 20 years of programming (2020)
alexewerlof.medium.com
My guiding principles after 20 years of programming (2020)
1–10 of 193 posts
Re: My guiding principles after 20 years of programming (2020)
#2Amendment to #1: if the right tool for the job doesn't exist, find a cheap way to make the tool. Toolmaking is highly leveraged work.
I like the list! There are some things I would replace with other things (overall, I think I'd emphasise more general business and product development aspects more) but of course, everyone has their own list!
Re: My guiding principles after 20 years of programming (2020)
#3I don't know how I feel about the insistence of having pet projects and learning something new every day. It feels like a very work-centered approach to life.
Unless of course the pet projects happen at work during working hours, but finding a place that allows that is probably a whole different kind of beast.
Re: My guiding principles after 20 years of programming (2020)
#49 times out of 10 somebody else's code points the way. The tenth time, you didn't look hard enough. The exception to this rule lies in a very small % of coders who know who they are.
I hasten to add, I am not in that minority!
Re: My guiding principles after 20 years of programming (2020)
#59 times out of 10 somebody else's code points the way. The tenth time, you didn't look hard enough. The exception to this rule lies in a very small % of coders who know who they are. I hasten to add, I am not in that minority!
I realized at about 10 years into my career I would rewrite code as it was easier than learning someone else’s implementation.
Now that I’m cognizant of this I first thoroughly review other implementations to try and understand why decisions were made, ultimately saving me from repeating the same mistakes.
Inconsistent documentation is also a problem.
Re: My guiding principles after 20 years of programming (2020)
#6I don't know how I feel about the insistence of having pet projects and learning something new every day. It feels like a very work-centered approach to life. Unless of course the pet projects happen at work during working hours, but finding a place that allows that is probably a whole different kind of beast.
Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.
Re: My guiding principles after 20 years of programming (2020)
#7I don't know how I feel about the insistence of having pet projects and learning something new every day. It feels like a very work-centered approach to life. Unless of course the pet projects happen at work during working hours, but finding a place that allows that is probably a whole different kind of beast.
Gather a bunch of co-workers and lobby for 15 % time! You should absolutely have some time for pet projects at work.
I think it's amazing if one can claim with a straight face people should `absolutely` be paid for pet projects at work.
Re: My guiding principles after 20 years of programming (2020)
#8My big tip, always change the problem to fit the resources you have.
If the problem is hard, don't solve it, change the problem.
Re: My guiding principles after 20 years of programming (2020)
#9Here'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, such as Windows Registry, environment variables, installed dependencies, daemon services, etc, scoring full points.
3. All publicly observable behavior is a liability. Also known as Hyrum's Law: "all observable behaviors of your system will be depended on by somebody", or https://xkcd.com/1172/. Huge multiplier for systems with a long expected lifespan, and another huge one if you guarantee backwards compatibility to paying customers. Program under this assumption, and if you can hide or control your internal behavior, do it. E.g.: maybe don't output results reliant on a HashSet order - sort them.
None of these are hard 'rules'. Often the liability is necessary, or worth the saved effort or gained feature. But be aware of them, and minimize them where possible.
Re: My guiding principles after 20 years of programming (2020)
#10> 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 really resonate with me too) but I think this one is my favourite. One strategy I've used which is successful - but not very popular - is "readme based development". The concept is simple, if we're building something new then the first thing we should do is summarise the project in the readme. If we spend time describing the problem and scope of the project and finessing it down to a few sentences before we start coding then we should have a better chance of staying on track and have an easier time communicating with others. The bigger the project the more useful this can be but unfortunately the majority of folks I've worked with do not like writing.