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

281–290 of 327 posts

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

#281

Post by TeMPOraL »

tmoertel wrote: post #264
josephg wrote: post #199

Earlier quoted context omitted.

Yep. I’ve heard this talked about as Voice and Exit . They’re two strategies you almost always have available: essentially, speak up or leave. If all the people who care about a problem leave, it becomes harder for the organisation to solve the problem. This is one form of organisational rot. Most of us are good at one and bad at the other. Eg, my instinctive response has been to quit my job when I’m not enjoying it.…

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.

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

#282

Post by osigurdson »

redserk wrote: post #269
osigurdson wrote: post #230

Earlier quoted context omitted.

That is ok for some but others want to feel like there is some point to the 2/3 of their life that they spent working and preparing to work (i.e. school). For some, punching the clock and collecting a pay check isn't enough.

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.

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

#283

Post by thinkingtoilet »

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…

Treat the disease, not the symptom. Always good advice.

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

#284

Post by rightbyte »

kortilla wrote: post #254
squeaky-clean wrote: post #224

Earlier quoted context omitted.

All the "10x programmers" I've ever met have been taken advantage of way more and been used as company slaves more than the "clock watchers". I'll "bend over" and be pleasant during a meeting. Then on Friday night I leave work, have a date night with my girlfriend and have to silence Slack because the 10x guy got suckered into working on some odd feature instead of living life. In the end, I get the same salary and t…

You don’t get the same salary and equity as a top performer. Very few companies give flat raises and bonuses without taking into account performance. And if your manager cares about productivity, the 10x programmer is going to take the cake.

The correlation between performance and pay is really weak.

In my experience, probably negative too, since most work seem to be done by junior employees while the most seniors coast around fixing some bug every now and then on something they wrote some time ago.

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

#285

Post by osigurdson »

One bit of programming advice I would give myself is, on large projects, ensuring that appropriate constraints are in place is more important than functionality. You want to be able to come back to an area of code after a few years (without looking at it) and everything that has been added should still make sense. Patterns that you don't want to see should be hard to do - the natural inertia will stop it from happening. Designing things that "allow people to do anything", while seemingly a benefit, end up causing a lot of problems in the long run.

A reasonable argument might be that it should be watched / policed but this is harder in practice than in might seem. A lot of orgs are fairly decentralized, meaning that no central entity can make the call (probably a good thing imo). If appropriate constraints are designed into the system this kind of energy sapping discussion will not even need to happen in the first place.

Essentially, adding constraints at t0 adds degrees of freedom in the future. Coding is a bit like a garden - you need to ensure that the garden makes sense as it grows.

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

#286

Post by wruza »

gverrilla wrote: post #252
wruza wrote: post #168

Earlier quoted context omitted.

Now I just open vscode with default settings and I am productive right away. I am right away distracted by a huge rectangle around cursor line, current word highlighting and general jumpiness of everything. Coding in vscode feels like writing a book in the middle of brazilian festival. And then it cannot do random simple things like proper indents or humane snippets. The amount of work required to unfuck vscode is re…

I'm a novice. I have only used vscode and sublime. Both have a problem when copying code from elsewhere, where the indent will be wrong every time somehow. If that's what you're talking about, is there an editor that will figure it out correctly somehow? Thanks

I was talking about nested indents, like this:

  f(a,
    b, g(c,
    d
    )
    )
Vscode cannot indent it properly due to how indent rules (simple regexes) work. Formatters like “prettier” exist but they can only format whole-file. Maybe try that (downside being you’re at its mercy completely).

I guess you are experiencing either auto-indent like that or the partially selected lines problem (when selection doesn’t touch \n at both ends). Vscode and sublime should also have a way to “paste raw” without reindenting. Try copying proper non-partial lines and/or pasting raw at column 0, removing automatic indent and adding yours afterwards. I know it’s tedious but I’ve seen enough people editing in ms-style editors and they all had this issue. Most just accept it as a fact of life.

As a vim user I’m afraid I can’t help much here. My copy-pasting is almost always line-oriented (V-mode copied lines always pasted after current line, regardless where the cursor is) and indent rules are very robust so it rarely indents things wrong. I also have gv> and gv= to re/indent just pasted text. I’d ask on stackoverflow (stackexchange) or on HN which popular editors have whole-line modes or maybe vscode/sublime plugins which can help with that.

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

#287

Post by isotropy »

feoren wrote: post #236
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.

Nobody could easily explain why early (1950s - 1970s) fusion reactors were so difficult. It must have been that everyone was stupid and creating their own problems. No one can explain why the Collatz Conjecture is so hard to prove. It must be because everyone is so stupid and is adding incidental complexity to the problem. Why is everyone so stupid? Or, maybe, possibly, that advice is utter bullshit nonsense and some…

Fusion: Turbulence, plus Naiver-Stokes was known to be hard, plus adding in EM fields, plus the exothermic state change of the nuclei fusing introduces discontinuous jumps in the free energy.

Collatz: if you replace 1 and 3 with arbitrary parameters, Conway showed that this class of problems is undecidable, so any particular instance could be arbitrarily hard.

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

#288

Post by wruza »

j45 wrote: post #150
farmeroy wrote: post #125

Earlier quoted context omitted.

I've been using neovim pretty much since I began programming. I had some initial setup and have tweaked it once or twice, but it's by no means been a source of sunk time for me. I recently had to switch to VSCode and had a lot of issues learning all the out of the box key bindings and not having the telescope and fuzzy find windows I was used to was a huge productivity loss for me. When I able to jump back to neovim…

I'm reasonably familiar with both and use them for different cases than each other. vscode at least is my text editor in the gui... but consistently growing :) The time getting up to speed on something new shouldn't be used against something else that is already familiar. Now if the new tool (ie., vscode) could import your neovim setup and get you an equivalent, that would be neat. Comparing the sunk cost time for ne…

As a vim user, I think both worlds are crappy in their own way.

Vim has: a good editing model, good settings, programmability, arcane controls and language.

Ms-style usually has: extensive plugin systems, poor settings, poor editing model.

I wish there existed an editor/IDE which would consist of a good editing model, good settings, programmability and extensive plugin system, but without arcane controls and language.

Basically take vim, remap keys so it becomes ms++, replace vimscript with ts, add optional regular vscode around it. This editor would kill them all, imo.

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

#289

Post by mlhpdx »

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.

Define “free fall”, please. There seem to be plenty of interesting openings as far as I can tell. Less hysterical hiring, but plenty of work (and more interesting than the endless CRUD of 15 years ago).

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

#290

Post by wruza »

Panzer04 wrote: post #246
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…

Curious why you'd skip low level. Pay? Industry? Knowledge not helpful?

Because I ended up doing “business” things that are far from low-level, and I sort of like it, never wanted to return to C/asm.
Post reply on HN