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

171–180 of 327 posts

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

#171

Post by 999900000999 »

oblio wrote: post #164
999900000999 wrote: post #158

I'll add one point. You are not your job. Don't take things personally at work. And never be afraid to leave if you're not fitting in with your company . I've left jobs over a few reasons, primarily bad managers, increased compensation, and bad code . If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away . Don't embarrass an…

Unless you have a lot of flexibility in terms of where you work, this type of advice is becoming less relevant in an IT job market that's in free fall. Much fewer devs can just jump ship at will than between 2003 - 2022.

In my situation it would have been much easier to just keep my head down until I was able to get another job. I ended up causing a lot of tension at work, the engineer who had wrote this code openly resented me .

Usually when people are putting broken code into the code base it's a wider cultural problem, that you're not realistically going to solve.

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

#172

Post by moonshinefe »

vitus wrote: post #73

The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is "When working on a team, you should usually ask the question". Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an a…

It can go both ways. The most common one I've seen is definitely taking too long to ask about something. The other is asking too many trivial questions about things you can look up in minutes or ought to know given your job.

I think the problem is knowing when to ask is like many things a skill that gets better with experience. It isn't obvious especially to newer people. I also think if you're a senior you should be much more forgiving of juniors when it comes to this stuff. We were all there once.

I think asking too slowly tends to be caught more easily in things like standup before it snowballs. Asking too quickly tends to be habitual and seems to do more damage since it's harder to notice when managing projects, and often under the vague auspices of "pairing."

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

#173

Post by simpaticoder »

"Don’t underestimate the value of digging into history to investigate some bugs." Valuable advice, and it particularly highlights the risk of global state and the benefit of understanding your runtime. Browsers have popularized flamegraphs, stack traces show you the frames down to the moment of error, but global state survives multiple stack traces and the one you're looking at may not be (probably isn't) the cause of the problem. There is global state, the heap, external systems, etc that change over time and with successive calls. This is true even in single-threaded environments, and is far more complex in general multi-threaded environments. I often feel this isn't clear to beginners nor is it clear to them how you go about investigating bugs within this context.

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

#174

Post by marcusbuffett »

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?

That was more of a subtle joke than anything substantive. I think JIRA is probably fine as long as it’s not like a religion

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

#175

Post by wavemode »

bigdict wrote: post #170
austin-cheney wrote: post #169

The one piece of advice I would give myself 15 years ago: In the corporate world be very good at administration. You only need to just be good enough at programming to not get fired. Everybody has opinions on software techniques and nobody measures anything, so it’s really just a popularity/tool game. The only goals are retain employment or promote out of software, being good at software is just a distraction from th…

Could you expand a bit on what you mean by administration?

Not OP but I would say, generally non-engineering things that keep the business people happy. Project planning, delegating tasks, dashboards and metrics (customer feedback, if you can acquire it, is a big plus), setting and meeting deadlines, and knowing how to sell yourself.

There's that old (and very true) wisdom that if you solve a complex problem in two days, the business people won't think "wow, this guy is so smart and hard-working for solving that in 2 days." They will think "oh, this problem must not have been very hard to solve. Let's assign him extra work." Being a good engineer only gets you so far, career-wise.

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

#176

Post by austin-cheney »

bigdict wrote: post #170
austin-cheney wrote: post #169

The one piece of advice I would give myself 15 years ago: In the corporate world be very good at administration. You only need to just be good enough at programming to not get fired. Everybody has opinions on software techniques and nobody measures anything, so it’s really just a popularity/tool game. The only goals are retain employment or promote out of software, being good at software is just a distraction from th…

Could you expand a bit on what you mean by administration?

Writing ample clear documentation, precision of communication, dutifully fulfilling all timesheets, logging of work performed, attending all requested meetings, and always delivering work on time.

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

#177

Post by moonshinefe »

Good post, I agree with most of it. One that goes hand-in-hand with "just ask the question" is learning to know when to pivot. If you've hit a blocker, whether it's something to do with waiting on a teammate, client, or answer to a hard question, consider pivoting to another task to knock out some easy wins.

Ideally the task you pivot to should require minimal context switching to get going. This way you won't lose productivity. Often if the blocker is a hard problem and you go back to it later, you might have a good idea after stepping away for a bit as a bonus.

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

#178

Post by penteract »

cess11 wrote: post #120
penteract wrote: post #75

Earlier quoted context omitted.

Tutorials include some code which is intended to be exemplary and simple enough for a new programmer to make sense of, so I wouldn't discount it as a part of reading code. Practical code does not always have those properties, although you'd certainly be missing a lot if you only read code from tutorials. I completely agree with the claim "There is no substitute for doing", and I might even say that code you read with…

Trying to learn to become a developer from tutorials is like trying to become a carpenter by reading instruction manuals for saws, nail guns, &c. To learn how to implement computer programs, read books about it.

We might have different ideas about what constitutes a tutorial. Online tutorials vary massively in quality, but something like the official Python tutorial https://docs.python.org/3/tutorial/ is a fine resource. I would even say that the categories are not mutually exclusive - I would call "Structure and Interpretation of Computer Programs" both a book and a tutorial. Different people probably find different resources most helpful.

Also, "To learn how to implement computer programs, read books about it." contradicts the original comment's "There is no substitute for doing" more than I'm happy with.

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

#179

Post by roughly »

I think this is great for the craft of coding and solving problems. I’d add one more, along the vein of career advice: you’re hired to solve problems for the business, not to solve technical problems. If you can’t explain how the thing you’re doing makes an actual difference for the business, you need to reflect on what you’re spending your time on. I’ve seen too many technical teams be far too fixated on technical problems and unable to understand why they can’t get more headcount, funding, or recognition. Nobody writing checks cares about code.

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

#180

Post by roughly »

999900000999 wrote: post #158

I'll add one point. You are not your job. Don't take things personally at work. And never be afraid to leave if you're not fitting in with your company . I've left jobs over a few reasons, primarily bad managers, increased compensation, and bad code . If people are writing bad code at your company, to the point where you know it's going to come back to haunt you later, it's okay to just walk away . Don't embarrass an…

Related, the computer doesn’t care about you and isn’t judging you when it throws an error. Your code has the bug, not you. Stop feeling shitty about yourself and go fix it.
Post reply on HN