Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

261–270 of 534 posts

Re: Absolute truths I unlearned as junior developer

#261
post #48

Earlier quoted context omitted.

This is true with basically everything. Game development attracts more than its fair share of truly horrid code, to the point where success seems almost inversely correlated to code quality. If you decompile Terraria (using CIL, which preserves the object design), for instance, you'll notice that its main class is over 40kLOC and that basically all of the business logic is encoded in one great big chain of if-stateme…

> all of the business logic is encoded in one great big chain of if-statements One of the big lies of OO design is that you can manage that kind of complexity better with objects/classes, that you should factor out functionality into tiny pieces, and so on. Unless you have written (and debugged!) an actual video game, you should spare your judgement.

Exactly, having conditionals being spread throughout the program is a great way to increase complexity.

Rules engines, statecharts and other forms of (declarative) behaviour modelling solve real problems.

Re: Absolute truths I unlearned as junior developer

#262

Earlier quoted context omitted.

Comments rot, and details about what is going on is better incorporated using good variable names and functions that abstract aspects of a task from their implementation. While I don't like comments that try to explain what code is doing (write better code), comments are very useful for annotating WHY code does what it does. They're also very useful for adding documentation references, code use gotchas and things tha…

I've heard these sentiments very frequently from junior programmers, and almost never from senior programmers.

Complete opposite for me.

Re: Absolute truths I unlearned as junior developer

#263

Developers are new factory workers. Pay is good now because industry is expanding and there's not enough of us but it won't be like that forever. And bottom line work is already being commoditized (WordPress ecosystem etc).

From a hiring perspective, the problem is, and will continue to be, the quality of each worker. Although there are a handful of similarities between how the two professions operate, I think that it is unwise to make the factory worker connotation.

The entire idea of a factory worker is that they can be swapped in place by another and the output is maintained to a great extent. This just simply isn't the case in software or really any creative work. Even if we assume two workers have equal skill sets, something that is already dubious due to the importance of cross-domain knowledge in software, the personality one brings to a team will ultimately alter the entire team, sometimes good, sometimes not so. The social dynamic within groups is a critical element and something that cannot be commoditized away like other professions.

As to the point on commoditization within old tech, I can only answer with a "well duh, It's tech!". The goalposts are always moving within this profession. There used to be a whole heck of a lot of jobs in programming super low-level tasks, those are largely gone and have been replaced with new positions. Last year everyone worked on web apps, this year everyone was on mobile apps, next year it's anybody's guess.

Re: Absolute truths I unlearned as junior developer

#264
post #40

About two years ago, I didn't get a promotion to "senior engineer" that I thought I was going to, and I had a huge temper-tantrum to my boss about it as a result (I'm still surprised to this day that I didn't quit on the spot, to be honest). I was upset, because people that seemed to be contributing less and were less-qualified (at least from my admittedly-biased perspective at the time) were promoted to a higher lev…

I've always found the obsession with titles somewhat strange in our business. In my 7-8 jobs since college, I've never really had a 'formal' title. It just seems like all 'developers' are thrown into the same bin, and the better ones are team leads who don't have any actual authority to do anything (e.g. order a new laptop or approve of a hire).

After about 10 years, I just started calling myself a 'senior software engineer' on my resume and nobody has ever called me out on it.

Must be a Silicon Valley thing tied to salary. But in the areas I've worked, titles don't seem to exist for non-management.

Re: Absolute truths I unlearned as junior developer

#265
> "Good enough is good enough"

+1000 to this. Please don't be the guy that slows me down and prevents me from delivering features because you insist on everything being perfect. I can't tell you how many times and how much money people who are obsessed with code quality waste. They spend months polishing code only to get out a feature that no one uses and doesn't matter. But hey, the code is "perfect"!

Re: Absolute truths I unlearned as junior developer

#266
post #48
post #7

The big one for me was the realisation that the code doesn't matter . I mean sure, it does, to us. It's what we do. But really, code doesn't matter. To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for. And to the company we work for, what matters is that we solve the end user's problem, and that we do so in a…

This is true with basically everything. Game development attracts more than its fair share of truly horrid code, to the point where success seems almost inversely correlated to code quality. If you decompile Terraria (using CIL, which preserves the object design), for instance, you'll notice that its main class is over 40kLOC and that basically all of the business logic is encoded in one great big chain of if-stateme…

This is very far outside my realm of expertise but isn't it possible they're running some sort of obfuscation on the binary before releasing? 40k LOC seems unbelievable to me, surely even scrolling around in a text editor would be laggy as hell.

Re: Absolute truths I unlearned as junior developer

#268
post #168

Earlier quoted context omitted.

> If you still believe this, then - to be brutally honest - I would question the quality of the team's you've worked with. To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week. My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even i…

I don't understand what sort of environment you work in where you don't encounter situations where comments could add clarity to the code. Do you never see code that has global side effects? Or that is written a particular way to take advantage of the hardware that it is running on? Or any other of the many ways that the intention and meaning of a piece of code within the codebase it exists in can be not immediately…

>Do you never see code that has global side effects?

The answer for modern languages and frameworks is "write pure functions."

>Or that is written a particular way to take advantage of the hardware that it is running on?

Move to service/helper/utility class for that particular hardware or with a name that clarifies it's for that particular hardware.

I find comments to be necessary very rarely. Atm looking at a codebase where they are made to cover up for a lack of desire to think.

Re: Absolute truths I unlearned as junior developer

#269
post #15

Admittedly, 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."

Your comment came at the perfect time. I just finished debugging a "high urgency" problem with a program I developed and maintained for the past 10 years.

The program started simple with a small list of rules to apply against data sets. Over time the list became a tree of rules that expanded in both breadth and depth. It was refactored once to get the design in line with the rules of the time.

The "high urgency" issue turned out to be the program working correctly. But, the functional user wasn't able to keep in mind some of the rules he set. It took me a half hour, with lots of "why did I do that", to explain it again to the user.

Re: Absolute truths I unlearned as junior developer

#270
post #15

Admittedly, 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…

Things I've learned: I'll never be a senior programmer.
Post reply on HN