ProgrammingAdvice

Here are some classic posts that I need to sort through and organize:

• SummarizingChooseBoringTechnology
• Drunk Post: Things I’ve learned as a Sr. Dev
• Parse Don’t Validate
• Some Were Meant for C
• Teach Yourself Programming in 10 Years
• Roots of Lisp

Here are some software philosophy thoughts:

• “I need privacy, not because my actions are questionable, but because your judgement and intentions are.”
• UI is a contract - don’t break a user’s ability to automate

Here’s a collection of programming advice from people reflecting on their career.

A Bunch of Programming Advice I’d Give Myself 15 years ago - Markus Buffet

In this article, Marcus Buffet consolidates programming advice that he’d give to himself 15 years ago. Here’s the advice he gives:

1. If you (or your team) are shooting yourselves in the foot constantly, fix the gun
2. Assess the trade-off you’re making between quality and pace, make sure it’s appropriate for your context
3. Spending time sharpening the axe is almost always worth it
4. If you can’t easily explain why something is difficult, then it’s incidental complexity¹, which is probably worth addressing
5. Try to solve bugs one layer deeper
6. Don’t underestimate the value of digging into history to investigate some bugs
7. Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code
8. Make debugging easier
9. When working on a team, you should usually ask the question
10. Shipping cadence matters a lot. Think hard about what will get you shipping quickly and often

My Reflections

Advice entries 2, 7, and 10 resonate with me. I had a senior co-worker that managed his efforts really well. He designed and maintained a complex authoring system for demanding customers. When looking through his code, you’d occassionally see something and wonder “why didn’t he write this more flexibly?” He didn’t need flexibility. He needed to fix a problem in a short amount of time. The code would only be used for that application. If it needed to be changed in the future, it could. It was good quality bad code. I admire the skill to recognize what you don’t need.

Regarding difficulty and incidental complexity: I appreciate that this advice takes a trigger (can’t explain difficulty) and pairs it with an action (reassess complexity).

Lessons Learned in 35 Years of Making Software - Jim Grey (via Lobst.rs)

1. Do things in the most strightforward way possible. (i.e. don’t be clever)
2. There is no substitute for working software in Production.
3. Relationships matter if you want to advance.
4. Relationships matter if you want to see your vision come to live.
5. Never be invisible.
6. Build and maintain a network of people in our field, outside of the company that you currently work for.
7. Be willing.
8. Chase adventures and interestingness, not salary and title.
9. Challenge yourself to stretch past your natural tendencies.
10. Understand thtat different social classes have different ideas about how the world works.
11. When you deliver work you’re really proud of, you’ve almost certainly done too much and taken too long.
12. The software we are building right now will one day be decomissioned and not be used anymore, probably before your career is over.

My Reflections

Number 11 is controversial in the comments. In my own experience in enterprise tech, it’s more often true than false. Mostly because number 12 is inevitable in the enterprise world. Actually, I’d argue that number 12 underlies every other point in this advice. Ironically in enterprise tech, the technology is transitive, but how people feel about you after the focus shifts endures longer.

Summarizing 5 Software Engineering Footguns

source via RSS

As part of his series about learnings from auditing startups, Ken Kantzer lists five common “foot guns” that he calls the hardest to undo.

1. Writing clever code instead of clear code.
2. Not being willing to throw it all away.
3. Creating abstractions prematurely.
4. Not properly respecting the complexity of distributed systems.
5. Waiting too long to ask for help.

Number 5 is interesting. Sometimes it helps to have an expert identify things that you don’t know to ask. Sometimes, it’s better to bump along and maintain a so-called WTF notebook, so that you might smooth the road out for people that follow you.

Summarizing 5 Red Flags Signaling Your Rebuild Will Fail

source via RSS, last accessed 2024-07-26

Ken Kantzer discusses warning signs that rebuilding a s

1. No clear executive vision for the value of a rebuild.
2. You’re going for the big cutover rewrite.
3. The rebuild has slower feature velocity than the legacy system.
4. You aren’t working with people who were experts in the old system.
5. You’re planning to remove features because they’re hard.

Takeaways - I think Ken hit the nail on the head that people want to rebuild because reading code is harder than writing it and that that’s not a compelling enough reason for a scrap-and-reubuild.

Note: I think Joel Spolsky first articulated that code is easier to read than write, therefore everyone wants to rewrite.