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

201–210 of 327 posts

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

#201

Post by dandrew5 »

icedchai wrote: post #196
mostlysimilar wrote: post #187

Earlier quoted context omitted.

> 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. Citation needed. Good developers are just as in demand now as they have ever been.

It's supply and demand. Demand is lower (less jobs.) Supply is higher (more layoffs, people looking for work.) Even if you are "good", there's a lot of other "good" people looking, too. Some even may be better than you! Or at least better at marketing themselves.

Marketing yourself is more important now than ever. The advent of AI has created a noise problem at the hiring level on both sides: applicants are leveraging tools to generate necessary documents (targeted resumes, cover letters, social profiles), recruiters are using scanning tools to weed out anything that doesn't contain the magical keywords or phrases.

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

#202

Post by Zenzero »

BiteCode_dev wrote: post #85
Zenzero wrote: post #66

Earlier quoted context omitted.

> It's ok, doctors hurt people for years while learning to save them. Modern medical education doesn't work this way.

Yeah, I'm surrounded with medical professionals. It totally does. They make grave mistakes all the time. And they hide them. They lie about them. They have their ego and career on the line. And they don't have enough resources at their disposal, not enough hours, too many patients, and they are exhausted. In short, they are humans in a human system.

> Yeah, I'm surrounded with medical professionals

In fact you are. You're speaking to one.

Your original statement completely ignores the massive amount of barriers put up during your training. From my own experience I can tell you that students are usually quite self aware that they are learning and on a short leash. The most egregious mistakes I've seen were almost always a result of understaffing and gaps stemming from leadership issues coming from the top down. The small mistakes and cut corners are from tired overworked people.

Nobody accepts "hurting people" as a component of training. It's an absurd statement.

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

#203

Post by Anduia »

marcusbuffett wrote: post #174
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

I took it literally, sorry ^^

Thanks for your valuable advices!

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

#204

Post by 999900000999 »

icedchai wrote: post #195
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…

I disagree. If you have problems, you should try to escalate them. It's better for the company... it's better for your coworkers (they're probably also having these problems!) If you escalate them and nothing is changed, then it's time to go. If you're going to leave anyway , you may as well try to change things for the better first.

Or.

Hear me out.

You're going to then publicly embarrass another co worker. Not a good idea.

I need to clarify though, there's a difference between functional code that could have been written better, and code which does nothing at all .

I was at a company where three or four people literally were writing code that did nothing but was appearing to function correctly. Imagine an API that checks the status of another service, and you just code it to always return 200.

Instead of trying to save an organization from itself, you can just go somewhere else. I did so and I got like a $30,000 raise.

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

#205

Post by lolinder »

mostlysimilar wrote: post #187
oblio wrote: post #164

Earlier quoted context omitted.

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.

> 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. Citation needed. Good developers are just as in demand now as they have ever been.

The demand might be there, but if you have a proven way to get recognized as a "good developer" during the hiring process I'd love to hear it.

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

#206

Post by icedchai »

999900000999 wrote: post #204
icedchai wrote: post #195

Earlier quoted context omitted.

I disagree. If you have problems, you should try to escalate them. It's better for the company... it's better for your coworkers (they're probably also having these problems!) If you escalate them and nothing is changed, then it's time to go. If you're going to leave anyway , you may as well try to change things for the better first.

Or. Hear me out. You're going to then publicly embarrass another co worker. Not a good idea. I need to clarify though, there's a difference between functional code that could have been written better, and code which does nothing at all . I was at a company where three or four people literally were writing code that did nothing but was appearing to function correctly. Imagine an API that checks the status of another s…

Not necessarily. You can escalate things to your boss. Or then their boss. They talk to the coworker about it. It doesn't have to (and shouldn't be) a public inquisition. Maybe you do some one-on-one sessions / mentoring to try to help them. Maybe you're not patient enough to try this. It's certainly easier to leave most of the time.

The code aspect is all shades of gray. I've seen code that "functions" but has such unacceptable levels of performance, quality, duplication, security problems, etc. that it would barely qualify as "working" and certainly not maintainable. You can't polish a turd.

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

#207

Post by lolinder »

icedchai wrote: post #195
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…

I disagree. If you have problems, you should try to escalate them. It's better for the company... it's better for your coworkers (they're probably also having these problems!) If you escalate them and nothing is changed, then it's time to go. If you're going to leave anyway , you may as well try to change things for the better first.

It really depends on the context.

The important thing to realize is that bad developers who are kept around tend to survive because they're well liked by people who make the decisions. If you raise concerns about their performance then you're picking a fight that you can very quickly lose. I've seen people get hung out to dry when they escalate concerns about people like that, and even if they were right it still leaves them in a much worse position for their next job hunt.

In most cases I'd tend to agree with OP that the right move for an employee in that situation is to lay low and start looking. If the situation isn't yet completely unbearable there's no need to just hand in your two weeks' notice, but it's worth looking for the exits.

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

#208

Post by BhavdeepSethi »

Really great advice! Few that I would add based on my experience:

- Engineers spend way more time reading code than writing it. So writing easy to read code is more important than writing fancy/complicated code just because it saves few lines of code.

- Extension to above point. Having coding standards in the company is important so that it's for anyone to make changes to different parts of the code. If one engineer ends up writing code using their own standards, it makes life harder for everyone else on the team every time anyone else has to debug that code.

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

#209

Post by kccqzy »

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.

The market is not in a free fall. Or rather, it's only a free fall for junior fresh-out-of-college developers. If you are skilled and senior, don't believe this nonsense and have confidence in yourself. This is just an extension of the imposter syndrome that I see often in many people.
Post reply on HN