Things I wish I had known when I started programming, Part 4 (2019) | Hacker News Reader

Things I wish I had known when I started programming, Part 4 (2019)

brainstobytes.com

88 pointsjuanorozcov37 comments

I started programming a long time ago (more than 35 years) and if I could go back then I would've told myself that my code will live far far longer than I thought and was told then. This still applies. Most juniors I meet think their code will be tossed out in months or maybe years. It doesn't; it stays for decades. I still make the same mistake now when I write stuff; I was trying to fix some bugs in a system I wrote in 2 days and then hacked on for 2-3 weeks over time. It is a real (objective) mess as it was a hurry-hackjob and was supposed to be replaced within 3 months (I was doing someone a favor; that's how bad things start :); I realised looking in git that it is from february 2012... And used by millions/month since then.

If it were 35 years ago, this was probably some logistics or finance systems? These were the first things adopting computers.

Nowadays I'd say it's 50/50 whether a new project there will last a while. More than half the work is pet projects that won't ever be used for real, if at all. While the other small half can live for many years. It's possible to get a pretty good idea of where it's heading from the start, with experience.

> If it were 35 years ago, this was probably some logistics or finance systems?

35 years ago was also the time when 8-bit personal computers were becoming popular (well, not as 'popular' as 10 years later, of course) in homes, and hobbyists and kids could start dabbling in programming.

The start of 8-bit personal computers was around 45 years ago.

I thought I had insisted enough on popular.

I would have said that 35 years ago was the end of the 8-bit era. I had an Atari ST with a 20MB hard disk in 1985.

For me it was educational software for my first successful projects ; beginning on 8-bit micros but soon for MS-DOS, win3.1 and then win95 and onward. The 'business logic' code (written in Pascal by me) lived for decades inside the 40-something software packages being sold to most schools in my country.

> If it were 35 years ago, this was probably some logistics or finance systems? These were the first things adopting computers

Early adopters of computers were doing so in the '60s and '70s. By 1985 mainframes were widespread and PCs were becoming common. Check out [0]

1981: MS-DOS

1983: C++, ARPANET

1984: Common Lisp

1985: Excel

1987: Photoshop

[0] https://en.wikipedia.org/wiki/History_of_software

"Temp code" is the biggest lie anyone will ever tell you as a programmer.

Everyone will have perfectly good intentions, from PMs to directors to ICs, but "this is only temporary" almost never is.

I agree in some sense.

But I have found that every code base needs some kind of way to write "temporary" code AKA code that needs to be refactored at least.

If you don't define a place (and time) for this then it will happen anyway. Just all over your code base: patches, fixes, workarounds, todos.

The clearer it is to distinguish temporary code the better: "Start just writing what works here and then gradually move pieces of it over there, while testing and refactoring it."

When your code and communication is setup like this, then you will naturally incorporate this process because it is both pragmatic and very visible to everyone.

It's not specific to programming, though. For example, even after completing new buildings, I've never seen a school reduce the number of "temporary" portable classrooms they use to teach classes.

Right up there with "We'll come back and fix it", "We'll refactor it later" and "We can add the tests later"

It won't happen, and it has never happened unless those sections end up failing catastrophically.

We don't have enough money to do it right once, but we have enough money to it wrong twice - Me, 3 years ago.

I'm still regularly refactoring code I initially wrote 35 years ago. https://github.com/dlang/dmd/pull/11301

I would be too in your case, but all of my work is for clients, not for the 'greater good'... Keep up the good work!

No-one ever told me but myself. That's why I would tell my younger self that if I could with the hope it would stick long-term. I mean, in any other field (which we shouldn't compare to, but what else can we do that makes it sound as insane is it really is?) do you get something like; 'let's make an emergency bridge out of two planks over this bit of highway because the real bridge has been flooded' and then 25 years later people are still driving over those planks causing traffic jams and accidents (we have to ducktape those planks all the time)?

If I write something that is just to keep something running 'for a couple of days' and then ends up being part of a backbone for a company (because it ain't broken, so why replace it?) is something I could not expect but there are at least 50+ 'blobs of software' out there by me where exactly that happened over the decades.

"Temp code" is fine. In fact, I'll go a step further: it doesn't matter how shitty a piece of code is if you never have to touch it again.

The way you deal with "temp code" is to slightly improve the aspect you are changing, each time you change it. Maybe you did something weirdly hacky with magic numbers everywhere - when you need to add another magic number you refactor that aspect to no longer use them. Or maybe if they're starting to look more like types you do a refactor to enums or classes.

Then the places that can be shitty remain shitty. The places that can't are fixed up over time.

There's a book or two by Vernor Vinge where a character is a hobbyist "software archaeologist"; the character traces back one of the most basic programs -- I think it was the time//clock program -- and [re?]discovers the Unix Epoch of 1-Jan-1970. Because space-faring humanity in the far future runs on some flavor of Unix. The character concludes that that specific date was chosen because that was when humanity first walked on the moon.

The point being to reiterate yours -- there's a decent chance the code you write will survive in some form far longer than initially told or intended.

Pretty sure it’s the A Fire Upon the Deep / A Deepness in the Sky series by Vinge

https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep

It's from _A Deepness in the Sky_.

The actual epoch chosen was the time of the first moon landing, a little prior to 1-Jan-1970 (I like this touch, something with actual historical significance and likely documentable to a fraction of a second, rather than an arbitrary date).

It depends on a variety of factors. Availability* Is the code easily accessible to a wider audience?

Legacy system cycle* Was the code written in a system that is expected to have a long cycle? (20 years+)

Attribution* Can it be easily attributed to the owner?

Access* Do you have access to enough source codes to confirm it to be true?

Quality* Does the code have an appropriate level of quality?

Company* Did the company survive the peaks and through of capitalism even if it means being bought out?

> It depends on a variety of factors.

What depends?

the issue is that if you tried to write it to last 10 years it would be a different code base and wouldn't necessarily have gotten used like the one you actually did write.

The real take away here is that real (objective) mess hurry-hackjob code bases are good enough to last many years so you probably did the right thing.

My learning too, "stop-gap" code isn't always short-lived.

Many of the baselines I have worked on are littered with comments that begin with 'Todo: ...'. Developers facing a deadline or trying to close a ticket add the todo as a reminder and years later have not gotten back to it.

We just moved our main repo from a local mercurial server to Github. The Github UI does a better job of exposing the time since last commit, and man, it's fascinating realizing that some of the deepest core components were last touched 8, 10, 12 years ago. It really does live longer than you expect.

The article claims impostor syndrome goes away after a few weeks. For me it took many years to die down and it’s still always in the back of my mind a little bit.

Yeah, maybe it should've been something like 'it gets better/bearable' after a couple of weeks, I don't think it ever really goes away.

10 years in, and I still deal with it on a regular basis (I wrote [1] a little bit about this the other day). Hopefully it goes away one day, but I suspect it won't.

[1]: https://yorickpeterse.com/articles/10-years-of-software-deve...

I don't think it ever goes away until you make peace with who you are. Accept that some days you will be less productive than others. Accept that somebody else will always appear to get more done than you.

Give a look at Scott Adams's goals vs systems. Personally, when I stick to my system I am less likely to look to something else to judge if I'm "doing enough" and as a result, imposter syndrome doesn't have a chance to creep in.

Yeah, I remember at my first mid-year review I thought I was going to be reprimanded for lack of getting virtually anything done (not for lack of trying), only to get told I was doing great!

"Love maintenance work or at least learn to appreciate it" --- I _do_ love maintenance work. its like a massive puzzle / jenga-tower, have to be super careful about how to pull out and rearrange pieces.

Anyone know the best pay to stress ratio industry for this? Finance/Gov?

what's your usual timeframe to fix a bug ? are you allowed 4 weeks ? more, less ? or are you trusted to make it as long as it needs as long as you report regularly ?

as long as I report regularly, if i'm transparent and convey (with some acting + vocabulary skills) the breadth and complexity of how a bug needs to be fixed correctly, usually hte higher ups understand and probably subconciously are thanking the stars they dont have to deal with that 'code' stuff lol.

aight, cool

and I really wonder what happen in non coder's brains..

> You got your first software development job. The idea of being interviewed made you feel very anxious, but you studied hard and aced the whole thing. Finally, you arrive at the office on your first day and...

> And it's terrifying. Suddenly, you feel like a Jon Snow who knows nothing, and self-doubt starts to creep in.

I was very fortunate in my first position to not have any imposter syndrome, and I think it is partly because I did not ace the interview. I was honest when I didn't know an answer and showed I was willing to learn.

Has anyone here been in an organization where maintenance work was rewarded? How was it set up? Often times, maintenance is invisible, and people learn quickly what the incentives of an organization are.

Of course, the value of maintenance varies depends on the stage you're in. If you don't fully understand whether this is a market or not, then it's better to write quick sloppy code. If you understand the market and customers, then maintenance will reap rewards. How to convince your team to switch from one mode to the other?

It's nice to see a list like that, but really, many of these are lessons that need to be learned "the hard way" by actually suffering consequences.

Sure, they all sound plausible and we may have even been told these things by mentors during an internship. But is that going to stop an early 20-something from charging into into a project shit-storm? I think not.

Some things are best learned by trial and error, how else can you know the true pain these "commandments" help you to avoid?

Reply on news.ycombinator.com