Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A bunch of programming advice I'd give to myself 15 years ago

mbuffett.com

Post reply on HN
Print view View original

131–140 of 327 posts

Re: A bunch of programming advice I'd give to myself 15 years ago

#131

Post by aiisjustanif »

marcusbuffett wrote: post #7
BiteCode_dev wrote: post #3

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

These seem just as abstract as mine, if not more so, plus at least I provided examples where I could. Feels weird to criticize my post for general advice + examples, then come up with your own general advice without examples. Also this was just an analogy I know, but doctors definitely don’t hurt people for years while trying to save them, very different profession from ours, if anything doctors earlier in their care…

I really liked “You should know all the major shortcuts in your editor. You should be a confident and fast typist. You should know your OS well. You should be proficient in the shell. You should know how to use the browser dev tools effectively.”

Typing skills are severely underrated in order to professions and roles adject to our professions like PM.

Re: A bunch of programming advice I'd give to myself 15 years ago

#132

Post by hinkley »

The trick is not in having advice to offer. It’s in having advice they will hear.

Next month I’ll have been working in software for 30 years. Which means I would have a lot more common ground with me 15 years ago than most people will. that me with five years’ experience might not have understood at all.

Me with five years’ experience suspected many things that were true but missed some important one. I’d probably have to feed his ego by confirming some of those things before moving on to the difficult bits.

But who is to say that me with less Impostor Syndrome would be a better person? No, the main value in learning from the past is improving the future, not nostalgia or regrets or what ifs.

Re: A bunch of programming advice I'd give to myself 15 years ago

#133

Post by [deleted] »

avanai wrote: post #122

> Try to solve bugs one layer deeper This is one of the main things I try to impart to junior folks when I’m mentoring them or reviewing code. It’s also one of the biggest red flags to me of someone who’s working above their level when I have to repeatedly press a more senior person to dig deeper and fix things at a deeper level. You need to take the time to understand why the bug happened, or you’re just going to be…

[deleted]

Re: A bunch of programming advice I'd give to myself 15 years ago

#134

Post by hinkley »

avanai wrote: post #122

> Try to solve bugs one layer deeper This is one of the main things I try to impart to junior folks when I’m mentoring them or reviewing code. It’s also one of the biggest red flags to me of someone who’s working above their level when I have to repeatedly press a more senior person to dig deeper and fix things at a deeper level. You need to take the time to understand why the bug happened, or you’re just going to be…

I’m surprised by how many people cannot handle 5 Why’s. It’s substantially the same people who like wallpaper and putty.

Re: A bunch of programming advice I'd give to myself 15 years ago

#135

Post by trashburger »

Scubabear68 wrote: post #98

The author’s comments about knowing your business context and the potential impact of bugs really hit home with me. I have seen far too many teams using Facebook sized solutions for a few thousand users. I’ve seen developers slowed to an absolute crawl, terrified of shipping code, for a completely secondary operational platform with low volumes and non-critical data. All because the product people were misguided in t…

I am personally at the “nice tooling” level, but am currently building towards supporting other teams at the “business critical” level, so I try to apply the same rigour to everything that I do. It might make sense to also consider your dependents in similar scenarios.

Re: A bunch of programming advice I'd give to myself 15 years ago

#136

Post by hiatus »

avanai wrote: post #122

> Try to solve bugs one layer deeper This is one of the main things I try to impart to junior folks when I’m mentoring them or reviewing code. It’s also one of the biggest red flags to me of someone who’s working above their level when I have to repeatedly press a more senior person to dig deeper and fix things at a deeper level. You need to take the time to understand why the bug happened, or you’re just going to be…

> You need to take the time to understand why the bug happened, or you’re just going to be patching wallpaper instead of fixing the plumbing leak.

I think many would like to probe deeper but aren't afforded the time between sprint tasks. Management often pushes back for solutions that are good enough compared to exploration with an unknown duration until the solution is found.

Re: A bunch of programming advice I'd give to myself 15 years ago

#137

Post by j45 »

hamasho wrote: post #11

Most of this advice has already clicked with me, but this part: > If you can't easily explain why something is difficult, then it's incidental complexity, which is probably worth addressing That's a real eye-opener. Hope I remember this next time I implement something complex. The thing is, I don't think this stuff would've helped me much when I was a junior dev. A lot of them are just too nuanced.

'Addressing' can be ambiguous. Writing comments to explain why it's right and needs to be this way? Or changing the code without considering if they have enough knowledge of the rest of the codebase.

There's also a chance it's not understood yet to easily explain it.

A key part of joining a team is remaining open to the fact that just because I don't understand something, doesn't mean there isn't understanding in it.

Re: A bunch of programming advice I'd give to myself 15 years ago

#138

Post by dgb23 »

mannykannot wrote: post #39

I like this a lot. While those commenters who say it is too advanced for novices have a point, I feel these are still issues worth thinking about - and coming back to - as they learn. The one exception is “Bad code gives you feedback, perfect code doesn’t. Err on the side of writing bad code.” My experience with bad code is that it does not tell me much; instead, it presents inscrutable and baffling mysteries. From t…

The Bad Code advice is for people who have the tendency for perfectionism (apparently like the author 15y ago).

My advice to me: write simple, dumb, repetitive code, but make an effort to be consistent.

Consistent, dumb code is really easy to visually parse. The repetitions slide into the background and the differences stick out. The more code there is, the easier to see what goes together (data aggregates/structures), what the overall flow should be (control, conditionals, order etc.). Then it's easier to factor things out or how to express more clearly what the code does.

But again, consistency is key. The code can be "bad", but it's very beneficial to do simple edits like renaming and reordering of things, grouping them under succinct comments so the structure stays clear.

Younger me would do the opposite: inconsistent code that is complex. I think its impatience that gets in the way, rushing to build abstractions and factoring out things way too early or trying out competing ways to express the same kinds of things (playing around with code).

Every programmer has their own tendencies and their own journey, so they need to hear different advice, in order to ignore it for now, but to have an AHA moment at some point when they realize why the advice was given.

Re: A bunch of programming advice I'd give to myself 15 years ago

#139

Post by skydhash »

Anduia wrote: post #126

Funny how he casually mentions JIRA as a process that slows you down. I get that his team does the issue tracking somewhere else? What does people use that is faster to process both for devs and the PM?

It always depends on the team. And by team, I mean the people working on a somewhat independent part of the project (they don’t need to care about the minutia of some other parts). Issue tracking is a tool, but project managers always wants the tool to become the process. And that’s when you got daily standups, story points, epics, and fixed sprints (aka fake deadlines).

Use the tool as a tool. As the devs, add issue and tasks that needs the attention of the team, comments on a ticket for knowledge retention. As the manager, schedule the ticket if its completion matters in a particular timeframe, use assignments and other fields to manage workload. Do all of these to help the team get things done. Anything else is a hindrance.

Re: A bunch of programming advice I'd give to myself 15 years ago

#140

Post by CM30 »

Seems like some good advice here! The points about digging deeper into the cause of a bug and looking at the history of the codebase for more info are really good points to keep in mind for sure.

And remembering to ask questions hits home pretty well too. There's always the worry that you're bothering people too much, and the balancing act between thinking whether you need to be asking for help early enough to make sure you're not going down the wrong path and not asking about every little thing without attempting to fix it yourself...

Post reply on HN