Live data from Hacker News

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

mbuffett.com

301–310 of 327 posts

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

#301

This is interesting. If I were to complement the list, these are some items I’d add that helped me: - learn functional programming. Doing that was how I finally “grokked” programming and could solve problems more easily. Before I was ready to give up. - learn CS history. I studied UX and what I learnt was mostly one side of how to think about computing where you spoon feed users and remove things. There are other way…

"learn fundamentals: data structures, networking, performance, operating systems, security, unix, math. These are so neglected in the industry, and we’re left with super complex systems we don’t actually understand as a result." I sometimes hold a "command line fundamentals" course for my teams. Just being able to understand the basics puts them above any team that doesn't. You have to know the ground you're building…

> You have to know the ground you're building on. Otherwise even your foundation will be faulty

Exactly, well put. Knowing the fundamentals leads to a more solid, safer foundation as you understand better what you can do with what you have and avoid layers of abstraction.

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

#302

Earlier quoted context omitted.

[flagged]

> Your advice for being valuable is basically to slave away and follow your masters orders at daily scrum, not leave your box one minute outside of your allocated time , attend all bending over sessions and be pleasant as you take it , say what they want you to say with precision and always be whatever they want you to be i.e a massive people pleasing cuck with no principles that nobody can ever really trust or respe…

I think that it was the kind of screed that an incel might regurgitate

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

#303

Earlier quoted context omitted.

That model comes from Hirschman's treatise on Exit, Voice, and Loyalty . https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty

Feels a bit like a false dichotomy, in that there's at least one other option: wait it out . If you believe things will improve, the lapse is temporary, then doing nothing is a good move, and that's neither Voice nor Exit.

Totally right - it’s not a dichotomy. Those are just two strategies that happen to be broadly applicable. There are almost always other strategies available too, depending on the specific problem you’re facing. (Maybe you can fire the people involved. Maybe there’s a technical solution. Maybe you can ask for help. Etc etc.)

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

#304
post #164

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.

Don't just jump ship. But do actively look for better opportunities if you are not satisfied where you are.

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

#305

Earlier quoted context omitted.

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

I scratch my itch with side projects

That is cool, but often feels potentially less impactful. I take a slightly different view - maybe I am lucky to be fortunate enough to be in a position to make an impact - even though it is unlikely that I will benefit financially.

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

#306

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…

This resonates well with my thinking. Programming I do for money is quite different from programming I do as a hobby.

If I wouldn't keep them separate, I would lose passion to it fairly quickly.

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

#307

The one thing I disagree is the thing about editors. When I began coding I spent hours tweaking my vimrc file and learning all the essentially random shortcuts, and dealing with the absurdities of vimscript. (and debugging vim plugins that broke each other.) It felt like actual work while I was producing nothing. Now I just open vscode with default settings and I am productive right away. Who cares about editors, vsc…

> Now I just open vscode with default settings and I am productive right away.

Is always so painful to watch how slow average developers are with the tool they use the most. Using mouse/touchpad to scroll/select word is unbelievably slow. Learning and configuring text editor that is customizable enough to not get in a way pays dividends really well.

Programming is mostly reading and navigating through the code with "go to definition" and similar code actions. Just being able to do this really fast would give a huge productivity boost right away.

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

#308
post #295

Earlier quoted context omitted.

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.

>function1(){ ApiCall("1") }

>function2(){ ApiCall("2) }

Quoting from earlier in the thread, see this and tell me the person writing it is competent.

The polite way to put it is "there might be a skill mismatch".

Plenty of people get slowly drifted into programming roles they aren't qualified for.

At the end of the day, I'm not some super hero looking to drastically improve every company I work for.

It's fine to walk out if your not vibing with your co workers. Always say it's about money, you never know who you'll see again.

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

#309

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…

Also in addition to not being your job. I left a place that had interesting work, great management, great coworkers and excellent pay/benefits/growth. A place I once considered a dream job.

Why did I leave? Because I grew a little bored of it and wanted to try something different. I wanted to try and build my own company. Which is going good so far. (It's been about 14 months since)

I am not my job and thus it gives me freedom to pursue things because I want too.

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

#310

Earlier quoted context omitted.

I didn't have that experience, I was basically told that I should shut up and get used to working with code that doesn't functionally do anything . Then when I complain later my manager was like, even though the code doesn't do anything it makes our metrics look better. Imagine seeing function1(){ ApiCall("1") } function2(){ ApiCall("2) } Over and over again.

I'd tell them I am not shutting up and this is a major problem affecting the quality of the product. I would then speak to the boss's boss about it and start complaining about the boss doing a poor job, encouraging fake, meaningless metrics to game the system. Maybe they'll get get fed up and tell you to GTFO. Probably not though. The thing about broken organizations is that they take forever to fire anyone, so use t…

> The thing about broken organizations is that they take forever to fire anyone, so use that to your advantage while you look for other jobs.

My last place was horrendously broken in many aspects, and fired people at the drop of a hat.

Post reply on HN