6 ms·

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

88 points by juanorozcov 6y ago

tluyben2 6y ago
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.
- user5994461 6y ago
  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.
  - wott 6y ago
    > 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.
    - rjsw 6y ago
      The start of 8-bit personal computers was around 45 years ago.
      - wott 6y ago
        I thought I had insisted enough on popular.
        rjsw 6y ago
        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.
  - tluyben2 6y ago
    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.
  - KineticLensman 6y ago
    > 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 https://en.wikipedia.org/wiki/History_of_software
- protonimitate 6y ago
  "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.
  - dgb23 6y ago
    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.
  - lmkg 6y ago
    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.
  - WrtCdEvrydy 6y ago
    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.
    - WalterBright 6y ago
      I'm still regularly refactoring code I initially wrote 35 years ago. https://github.com/dlang/dmd/pull/11301 https://github.com/dlang/dmd/pull/11301
      - tluyben2 6y ago
- drdeadringer 6y ago
  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.
  - jodrellblank 6y ago
    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 https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep
  - kabdib 6y ago
    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).
- Polskanite 6y ago
  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?
  - tluyben2 6y ago
    > It depends on a variety of factors. What depends?
- drbojingle 6y ago
  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.
- abhgh 6y ago
  My learning too, "stop-gap" code isn't always short-lived.
- wonderwonder 6y ago
  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.
- el_benhameen 6y ago
  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.
dharmab 6y ago
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.
- juanorozcov 6y ago
  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.
  - YorickPeterse 6y ago
    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-development/ https://yorickpeterse.com/articles/10-years-of-software-deve...
    - ru552 6y ago
      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.
- scottLobster 6y ago
  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!
miccah 6y ago
> 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.
abledon 6y ago
"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?
- deleted 6y ago
  [deleted]
- agumonkey 6y ago
  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 ?
  - abledon 6y ago
    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.
    - agumonkey 6y ago
      aight, cool and I really wonder what happen in non coder's brains..
crispyambulance 6y ago
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?
iamwil 6y ago
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?

88 points by juanorozcov 6y ago

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.

user5994461 6y ago
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.
- wott 6y ago
  > 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.
  - rjsw 6y ago
    The start of 8-bit personal computers was around 45 years ago.
    - wott 6y ago
      I thought I had insisted enough on popular.
      - rjsw 6y ago
        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.
- tluyben2 6y ago
  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.
- KineticLensman 6y ago
  > 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 https://en.wikipedia.org/wiki/History_of_software
protonimitate 6y ago
"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.
- dgb23 6y ago
  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.
- lmkg 6y ago
  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.
- WrtCdEvrydy 6y ago
  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.
  - WalterBright 6y ago
    I'm still regularly refactoring code I initially wrote 35 years ago. https://github.com/dlang/dmd/pull/11301 https://github.com/dlang/dmd/pull/11301
    - tluyben2 6y ago
drdeadringer 6y ago
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.
- jodrellblank 6y ago
  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 https://en.wikipedia.org/wiki/A_Fire_Upon_the_Deep
- kabdib 6y ago
  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).
Polskanite 6y ago
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?
- tluyben2 6y ago
  > It depends on a variety of factors. What depends?
drbojingle 6y ago
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.
abhgh 6y ago
My learning too, "stop-gap" code isn't always short-lived.
wonderwonder 6y ago
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.
el_benhameen 6y ago
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.

dharmab 6y ago

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.

juanorozcov 6y ago
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.
- YorickPeterse 6y ago
  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-development/ https://yorickpeterse.com/articles/10-years-of-software-deve...
  - ru552 6y ago
    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.
scottLobster 6y ago
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!

miccah 6y ago

> 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.

abledon 6y ago

"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?

deleted 6y ago
[deleted]
agumonkey 6y ago
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 ?
- abledon 6y ago
  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.
  - agumonkey 6y ago
    aight, cool and I really wonder what happen in non coder's brains..

crispyambulance 6y ago

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?

iamwil 6y ago

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?