A bunch of programming advice I'd give to myself 15 years ago • Hacker News Board

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

#291

Post by wruza » Sun, Jun 30, 2024, 3:33 PM UTC

juangacovas wrote: post #242

wruza wrote: post #29

Not sure what 15 years means, but if that’s where I started: (Blasphemies warning) - Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good. - All the money is in the hands of a client. If you’re taking it from someone else, best case you’re taking less than a quarter for essentially the same job. Useless leeches everywhere who perceive y…

>Skip low level and go as high as you can. Ditch C, assembly, hardware. Take python, ruby, js. Never touched C++ cause it’s awful? Good. In my personal experience, I think that having to work on different high AND more low level programming languages over time is what sets me apart from people/coworkers with low basic knowledge of computer foundations (the order in my case being Basic, Pascal, C, Perl, C/C++, PHP, JS…

I think you’re right, I should have separated it in two parts. First is learning low-level “how it works, exactly” — that is useful. Second is writing actual low-level code — that I’d advise myself against.

So, I guess:

- Learn how sockets, filesystems and processes work, read apue, learn how jits/compilers work. But don’t write serious C, that’s a waste of time even if you’re smart enough.

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

#292

Post by glouwbug » Sun, Jun 30, 2024, 3:48 PM UTC

osigurdson wrote: post #282

redserk wrote: post #269

Earlier quoted context omitted.

US-based individuals here are making 2-3x (or higher!) more cash than the median family (not to mention other comp that easily exceeds a year+ of income of other families) If 4 years of school and sitting in an air conditioned home office for a few hours a day isn’t rewarding enough on its own, perhaps these folks should pursue perspectives of other people outside of their isolated tech bubble. I’ll take “bad but meh…

There is nothing wrong with that at all. Some people (myself included) are just wired differently.

I scratch my itch with side projects

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

#293

Post by klysm » Sun, Jun 30, 2024, 4:17 PM UTC

dan-robertson wrote: post #218

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…

It’s funny, this comment went in a totally different direction from what I expected based on the start. When you wrote ‘don’t take things personally at work’, I was expecting you to say things things about various kinds of humility – trying to make requested changes in code review instead of pushing back, not feeling wronged if someone rewrites something you wrote, etc – and seeing the bigger picture – the code exist…

A lot of my progression as a software engineer has come from decoupling my ego from the things I produce. That’s hard to do because the code you produce is a very strong reflection of your mental models and it’s justified to feel some connection to it.

Tactfully navigating this kind of thing in code review takes practice.

In my experience, the best teams of programmers work through problems with their egos held to the side.

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

#294

Post by mlhpdx » Sun, Jun 30, 2024, 4:30 PM UTC

nitely wrote: post #266

dgb23 wrote: post #263

Earlier quoted context omitted.

Honestly your reaction is very understandable. You tried to legitimately improve things, go the extra mile and they treated you badly for it. But ultimately that’s not how it goes in many places. There are a lot of people who care more about their craft than their ego. And this can be enriching beyond compensation.

I'll second this. There are a lot of good managers that care more about the product than some team metrics. Same for coworkers that care about improving. Don't let one bad manager define how you'll do things in your next job.

Likewise, plenty of people who care about the customers and their coworkers as well. Collaboration with such a teams is where it’s at.

In my experience such situations are transitory though and a time comes to move on (gracefully and maintaining accountability for one’s own actions).

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

#295

Post by mlhpdx » Sun, Jun 30, 2024, 4:33 PM UTC

recursive wrote: post #232

icedchai wrote: post #231

Earlier quoted context omitted.

I mean, if you don't care about the company, product, or project, then yes, you are right. Lay low and move on. Some fights definitely aren't worth it. If you do care about more than your paycheck, maybe it is. And do you really care if some incompetent hates you? I hate working with incompetent people, so some mutual feelings are perfectly fine. It may even improve the situation, at least temporarily: They'll reduce…

Bad impressions can be contagious. Some "incompetents" have political capital.

IMHO labeling people “incompetent” is a bright orange flag. Sometimes it is true, but far more often it’s a genuine lack of respect.

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

#296

Post by jiehong » Sun, Jun 30, 2024, 4:56 PM UTC

necrotic_comp wrote: post #96

valyala wrote: post #88

My advices to new software engineers: - Always think how to simplify the code you write, since simple code is easier to maintain and debug. - Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored. - Always think about improving the usability of the software product you work on. Users don't care about code.…

I go a step further on "dumb code". Write code that is easy to reason about, understand, and grok the implications of. I spent a ton of time doing support and engineering on a trading desk, where our SLA for an outage was somewhere in the range of 30 seconds to 5 minutes. Having super simple code that makes it easy to understand what the code problem is (if not necessarily the business problem) lets you move on with…

For writing simple code, I often remind people that the first working code is not the one to commit. Just like a text draft is edited, once the code works, now is time to trim it and simplify it.

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

#297

Post by seadan83 » Sun, Jun 30, 2024, 5:09 PM UTC

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.

Hard to compare the time period. I'm still coming to grips what it means when 95% of jobs I apply to are remote.

There are other data points to consider:

- higher interest rates and less VC money equates to less startups and less hiring

- large tech layoffs

To your point of demand for 'good' developers - I suspect that is likely true. I don't know how to decouple that from the problem of interviews not able to identify good developers. A 'good' developer is a function of the individual, what is happening in their life, the team, the codebase, leadership, process, tech debt, etc..

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

#298

Post by seadan83 » Sun, Jun 30, 2024, 5:15 PM UTC

rowanG077 wrote: post #250

lolinder wrote: post #205

Earlier quoted context omitted.

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.

References. Ask the good devs you have for someone good they know.

Anecdata incoming: a company I worked for had such a referral. They bombed the interview. The referring employee was incredulous. I was asked to re-interview them. They did seem good, they got an offer. The experience delayed things, put a bad taste in the candidates mouth, they took a different offer.

My point, the result of interviewing a good developer is potentially random. There is perhaps less probability of a bad developer having a random outcome as well, but certainly can happen.

Though.. define "good". Some people are incredible only when in the right team and environment.

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

#299

Post by seadan83 » Sun, Jun 30, 2024, 5:19 PM UTC

icedchai wrote: post #206

999900000999 wrote: post #204

Earlier quoted context omitted.

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…

That is a difficult escalation. When talking to your boss, it's almost always better to be discussing the solution to business problems, specifically those that are financially incentivized goals of your boss.

Talking about other problems, and suddenly you're 'that' guy. The boss might stop listening even and decide you are the problem, and not the fugly baby.

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

#300

Post by Viliam1234 » Sun, Jun 30, 2024, 5:47 PM UTC

seadan83 wrote: post #298

rowanG077 wrote: post #250

Earlier quoted context omitted.

References. Ask the good devs you have for someone good they know.

Anecdata incoming: a company I worked for had such a referral. They bombed the interview. The referring employee was incredulous. I was asked to re-interview them. They did seem good, they got an offer. The experience delayed things, put a bad taste in the candidates mouth, they took a different offer. My point, the result of interviewing a good developer is potentially random. There is perhaps less probability of a…

I have seen a few situations like this:

Company says "looking for an expert on X"

Expert on X walks into the room.

Interviewer: "How good are you at Y?"

Expert on X: "I know a little about Y, but not too much. I mostly use X for my work; I could show you how to solve the problem using X."

Interviewer: "Thank you for your time; goodbye."

When I tried to figure out why this happens, the answers are usually something stupid like: "HR posted the job announcement, they have no idea what we really need", or "yeah, we are still looking for an expert on X, but we need an expert on Y more urgently". (The latter still does not explain why they rejected the expert on X without asking him anything about X, but to the person who said this it seemed to make perfect sense.)