Interestingly, some of these absolute truths are absolutely true at larger (50+ devs, or so) companies because forward progress can't be made otherwise. System not documented? Might as well not exist at all. Code is not tested? Well, then nobody really knows if it works or not after even the most insignificant and peripheral changes. People don't treat code quality as a priority? Welcome to days/weeks/months of yak shaving to fix even the simplest issues. Good at communication but can't code worth a damn? Consider becoming a manager, not a "senior developer".
Absolute truths I unlearned as junior developer
351–360 of 534 posts
Re: Absolute truths I unlearned as junior developer
#352Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and…
> Learned as junior: New tech solves old problems.
> Understood as senior: New tech creates new problems.
Yep! When you use "new tech", you're making a bet, and not all bets pay off. If you're cautious, you'll hold off until new tech is proven (or pilot it cautiously before migrating). If you're possessed with good judgment, you'll be discriminating in which new techs you adopt. If you have both virtues, you may even gain a competitive advantage.
Re: Absolute truths I unlearned as junior developer
#353Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and…
> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. My first job was in finance and I remember one time that I had a glitch on a complicated Excel spreadsheet. I checked it over, checked again and checked again until I finally concluded that the bug was in Excel itself. So I go to my boss and tell…
It's unusual, but it does happen. My example is actually from hardware.
I was writing a Windows NT (what's that?) device driver for a communications board we developed for one of our products. I kept running into a problem and struggled with it for days. I was experienced enough to understand that the error was probably mine and the problem was so basic that if it was in the chip pretty much everyone who tried to use it in that mode would be screaming about it not working. The chip was an 8-channel UART (serial converter) and IIRC, the bug was in one of the FIFO interrupt modes.
Finally I gave up, got the phone number for the chip vendor's (I think it was Texas Instruments) local Field Applications Engineer and explained the problem to him. "Oh, yeah, we know about that bug, there's a new version of the chip about to be released. You guys are actually only the second customer to sample that chip. Lucky we found the problem before it went into production!"
Re: Absolute truths I unlearned as junior developer
#354Earlier quoted context omitted.
> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.
Yeah, whoever told you that has never had the sinking feeling of digging in to a 300 or 1000 LOC function with a pretty refactor in mind only to see just how much of the system relies on that one function. It's really only an issue if you try to be diligent about testing the work you produce, in which case that little refactor could cost your team a week or a month of additional testing while they verify that you did…
This is especially problematic in machine-control code.
I've seen code from an otherwise highly capable developer that contained 1000+ LOC functions. When asked why he couldn't do a refactor the answer boiled down to fear. When the only real way to test the code is by physically running a machine through a number of scenarios, many of which are difficult at best to recreate, you become very reluctant to refactor or clean it up.
Like all problems, it's best to nip it in the bud before things get that far out of line.
Re: Absolute truths I unlearned as junior developer
#355Earlier quoted context omitted.
I'm getting the statement about once a quarter at work of: Yeah I found this bug and I worked through it, did a bunch of googling or internal searching found a similar issue and welp it was a ticket from you (me) 2 years ago.
Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.
It drives me nuts when you find a forum post and they never reported back. Or it's a terse "I figured it out."
I try really hard not to do that for internal or public forums. The odds are better than you think that you'll stumble on the same topic a few years from now.
Re: Absolute truths I unlearned as junior developer
#356Earlier quoted context omitted.
> Understood as senior: Legacy code that I wrote myself is hard to read. Ha, yes, I occasionally come across code I wrote years before and have a few "WTF moments"!
I always find myself saying “Who is the shithead who wrote... oh...”
Its a good sign - means you are learning and getting better.
Re: Absolute truths I unlearned as junior developer
#357Earlier quoted context omitted.
> the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code. Then, when you get to debug it, you will be forced to improve your skills. This interpretat…
”Prod is on fire and nobody can figure out your burrito pasta” ”Isn’t this a wonderful learning opportunity for all of us” Debugging time is never a good time to start honing new skills.
“Burrito pasta” is a great term! Is that something that you just came up with?
It sounds like spaghetti code but even worse because it’s covered with a messy layer of beans and guacamole and wrapped in layers of tortilla.
Re: Absolute truths I unlearned as junior developer
#358Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and…
> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.
As I've matured as a developer I generally find it easier to read and understand code, whether it be my own or others. As a junior this is something I definitely struggled with.
Re: Absolute truths I unlearned as junior developer
#359Earlier quoted context omitted.
> > seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago. > What classes as 'senior' that their own coding style has changed that much in 6 months? O.o Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then…
...you don't remember what you were doing 6 months ago? I'm sorry, that's still not a good excuse. Maybe you don't remember every tiny facet but hopefully you'd have a general idea. And above all that, if you're a senior dev then you'd understand that "this code is unfamiliar" does NOT mean "this code is bad." I mean really, "this code is unfamiliar therefore it's messy therefore we should rewrite it" is a flaming re…
One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there. One of my biggest frustrations is that so many people don't bother, even when it would literally be just one little sentence.
Re: Absolute truths I unlearned as junior developer
#360Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and…
> If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Similarly, one thing I learned is that if I find a bug with an OS or platform, 9 times out of 10 it's actually due to some problem in my code or my own lack of understanding :)
Can suggest it's more like 999 times out of 1000?