Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

121–130 of 534 posts

Re: Absolute truths I unlearned as junior developer

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

Thats also a reason I will include as a comment the unoptimized code with comments whenever I do optimized crazycode.

That way, I can understand what is actually being done. And I can then re-analyze why I did the shortcuts to get to optimization.

But 99% of the time, we dont need to optimize. CPU/RAM is cheap. But those 1% of the times when you're going from N^2 to N^logN ... Welll.....

Re: Absolute truths I unlearned as junior developer

#122
I agree. Title doesn't matter. There is so much title inflation in the industry today.

For me, becoming a senior developer has allowed me to see code more objectively than before. Instead of following convention to the T, I can now look at code and make my own judgement whether to follow the convention. It's great to have the sense of relieve.

Re: Absolute truths I unlearned as junior developer

#123

I don't know if I can call myself a senior. (none of the companies I've worked for have used senior/junior in their job titles), but one of the most important pieces of information I've picked up is this: The Simplest way is usually the right way. What I mean is that fancy algorithms, sweeping design patterns, and "clever" pieces of code are generally not the best approach to 99% of coding specific problems. Example:…

Sidenote: I believe in general a Senior developer is 8-10 years with a general expectation that you will mentor junior developers.

YMMV depending upon region and company.

Re: Absolute truths I unlearned as junior developer

#124

Earlier quoted context omitted.

From Wikipedia: Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost. If you’re doing that you’re an engineer. Hopefully we are all doing that.

Unless you're in certain states where engineer is a protected term.

Exactly. I would welcome changes that would bring software engineering to a state where it was a protected term. If someone used that term I could have a high degree of certainty that they would abide by certain standards both professional and ethical. Such as “certain percentage of test coverage” and “certain big-O tolerance” for different project levels. Etc. otherwise I’d write the person off as a coder.

Re: Absolute truths I unlearned as junior developer

#125
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: Communication skills matter most. can you give examples ?

[deleted]

Re: Absolute truths I unlearned as junior developer

#126
post #74

Earlier quoted context omitted.

This is why calling people "coders" annoys the hell out of me. There was a popular blog post a long way back[1] about how you shouldn't call yourself a "programmer" because that builds the expectation that programs are the key output of your work. "Coder" takes this problem even further — your job is no longer to build a program (with all the thought and design work that entails), but rather to type out code. I'm not…

You're spot on. Regarding your last point though my interpretation of the blockchain hype was that the problem of the business was that they needed quick and easy money. Blockchain investors solved that.

Whether you perceive the problem as one worth solving or not, Bitcoin defined a very specific, if extreme, problem it wanted to solve, and proposed an extreme solution to that extreme problem. There's a few other projects (such as Ethereum) that are also trying to solve some very specific problems.

The issue is that the problems that Bitcoin and Ethereum are trying to solve imply almost generating money from thin air. That gave unscrupulous people a lot of silly ideas, on the one hand, and, on the other, gave the people desperate to prove they're "thought leaders" (whatever that means) a lot of different, but still silly, ideas.

Re: Absolute truths I unlearned as junior developer

#127
post #53

Earlier quoted context omitted.

Experienced developers know when to spend time making sure code is actually good and when a terrible crufty hack is fine. If you think "All code must be perfect" then you're not a pro yet.

And often business owners won't allow you to make that determination alone.

Like in any business area. But in the end, it's their business and their responsibility.

Re: Absolute truths I unlearned as junior developer

#128

Earlier quoted context omitted.

From Wikipedia: Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost. If you’re doing that you’re an engineer. Hopefully we are all doing that.

Unless you're in certain states where engineer is a protected term.

Engineer is not a "protected term" in any US state that I'm aware of. "Professional Engineer" has a specific licensed meaning but, if I have a degree in mechanical engineering I'm pretty sure I can call myself an engineer anywhere in the US without the licensing police coming after me. (Unless, of course, I imply that I'm licensed when I'm not.)

Re: Absolute truths I unlearned as junior developer

#129

> Documentation lies This is a very true statement, especially concerning legacy codebases. I have worked on some projects that have had several developers make changes to it. The original developers were great: they commented every class, had comments for all the methods, and added comments for any complex or funky logic. Then the changes came. And the next developers hacked and slashed the existing code base to mee…

I was thinking about this and because of the book _Clean Code_ I had already decided that comments will lie at some point.

So I moved towards descriptive variable and function names, but those could lie as well.

So I'm thinking, how could we ensure truthful intentions at all?

And I think only a combination of small pull requests, good variable and function names and a thorough review can save us here.

But I don't know, I'm just a junior developer.

Re: Absolute truths I unlearned as junior developer

#130
post #55

One thing the OP mentioned but I think isn't talked about much is that for me everyone has their own style. Some people have great abstractions, others lots of tests, some more code comments, interesting variable name choices, some like functional-style, or lots of frameworks & patterns etc. From our team I can often see who wrote something just from how its written. Now as a junior I just wrote how I liked and hated…

Interestingly, I'm at that unproductive phase right now. On one hand, I could fix this fast and ugly, but then my code is going to look no different then all the code I go home and complain about. On the other hand, I can try to make my code really nice and abstracted with well thought out design patterns like 's. So, on one hand I'm a hypocrite and on the other hand I'm slow and hardly productive because I am just learning design patterns and no matter how many times I refactor my code it never looks as good as 's. How did you get out of this stage? Please help.
Post reply on HN