Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

Post reply on HN
Print view View original

271–280 of 534 posts

Re: Absolute truths I unlearned as junior developer

#271

Post by bradlys »

asheikh wrote: post #115

My Absolute truth I unlearned as a Senior developer. your knowledge, hard work and quality of work is not important. The relationship that you have with your boss and your bank account is what you need to focus on.

This is something I've noticed early on even as a junior engineer (maybe it's my general upbringing that highlighted this well known fact of life). It becomes obvious quite quickly how little your knowledge and work matters. You can be incredibly smart and come up with wonderful solutions but it won't mean a thing if your boss(es) doesn't like you.

For a profession that has frequently professed meritocracy - it is certainly not. It's unfortunate.

Re: Absolute truths I unlearned as junior developer

#272

Post by mgolawala »

enobrev wrote: post #170
beat wrote: 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…

> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git rese…

The best feeling for me is when I come across old code and then re-write it to make it [simpler | faster | clearer | better] .. It is tangible proof to me that I have improved in my craft.

Re: Absolute truths I unlearned as junior developer

#273

Post by jehna1 »

scriptkiddy wrote: post #116

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:…

Premature optimization comes in many forms, and at least these three cases are doing more harm than good:

1: "It's good practice"

For example: Wrapping every function implementation in a memoize function may seem like a good idea (= it prevents doing unnecessary work-heavy stuff), but it actually makes code both harder to read (more boilerplate to skip when reading) and most cases slower (= even when a function is executed only once, you're doing extra checks and function call).

2. "We're gonna need this soon"

For example: many times I've implemented an abstraction that makes sense for sharing code with a feature that I know we'll be implementing soon, only to find out priorities have changed and that other feature never gets implemented. What's left is an unnecessary abstraction that only makes the code harder to read and maintain.

3: Optimising for speed/lines of code

Unless you're building a game engine, it rarely makes bang for the buck to optimise for speed until you have identified an actual bottleneck in performance.

Same for one-liners. It may be cool that you know how to write 10-line function as one-liner nested ternary, but your "clever" code is probably less readable and harder to maintain.

Re: Absolute truths I unlearned as junior developer

#274

Post by munmaek »

pdpi wrote: post #120
cc81 wrote: post #95

Earlier quoted context omitted.

Problem solver can be the title of pretty much any job though. "I'm a problem solver, I fix problems by diving down and welding broken things at oil platforms" "I'm a problem solver, I make sure the books are correct at the end of the financial year" etc. I mean it is correct but if someone calls themselves a coder/programmer/software engineer (even if they are not real engineers) then I know roughly what they are do…

Yeah, I wasn't entirely clear on that bit :) There absolutely is plenty of room for a word more specific than "problem-solver". But our choice of words matters — words carry nuance. In some ways I'd consider "software engineer" as equivalent to "novelist" or "journalist" where "programmer" maps to "writer" and "coder" corresponds to "typist". Software engineer, novelist, journalist all encapsulate a lot of responsibi…

I actually go the opposite route; I hate calling myself an engineer, because that word actually carries weight due to older, more established professions. The tech/software industry wants the prestige of that title without the work and effort that goes into it.

We are not engineers. We have no standardized certification process or tests. We have no (or very little) accountability. We have no codes of ethics. We may or may not be following proper, accepted development workflows. We may not even know what industry standard processes are.

I am a software developer because I solve problems primarily via software. This can and does include many different responsibilities and skillsets, but at the end of the day I primarily architect and write code.

It's up to you to educate the layperson as to what a software developer actually does. Although I'm not a writer, I understand that a "writer" doesn't literally only write. People can understand better than you're giving them credit for, I think.

Re: Absolute truths I unlearned as junior developer

#275

Post by pdpi »

rustyboy wrote: post #190
archagon wrote: post #86

Earlier quoted context omitted.

I dunno. I’m a programmer because I like solving problems through code, and I’m not really interested in solving problems outside this toolset. Some artists were exclusively painters, and we still call them that.

To you that's great, the article the parent was referencing is from a marketing perspective. He gives the example of quants, they solve financial problems with code. The same is true with data scientist, they just solve analytical problems with code. In both of these situations they're a programmer, but they sound cooler and will go a lot farther when applying for jobs or moving up in a company than the person who la…

A quant is somebody who specialised in solving very specific finance problems, and a data scientist is somebody who specialised in solving very specific statistics/data analysis problems. I wouldn't hire myself for a data science or quant role any more than I would hire a data scientist or quant for my role, because there's a whole bunch of ancillary skills that we each have that are required by our respective jobs that go above and beyond just programming.

Re: Absolute truths I unlearned as junior developer

#276

Post by Macha »

gmueckl wrote: post #243
RussianCow wrote: post #85

Earlier quoted context omitted.

> Sometimes I don’t even recognize me as the author for a while. This happened to me just yesterday! I was helping a co-worker with a problem, and I noticed some redundant code in the same function, so I told him he could simplify it while he was there. His response was, "...but you wrote that". (And as it turns out, only a few days prior!)

This is why I will point out issues in code only on the form of stating potential improvements as best as I can. I especially try to avoid hating on the author - it might have been me or the boss who's standing nearby... In fact, I often conciously refrain from using blame on an "interesting" piece of code because it doesn't matter who wrote it. Looking it up would just satisfy idle curiosity, but yield noninsight in…

My experience varies a lot. Maybe it's just my colleagues write better commit messages but blame (and looking up the PR and code review) is often a good method of understanding why the code is that way

Re: Absolute truths I unlearned as junior developer

#278

Post by tombert »

hiram112 wrote: post #264
tombert wrote: 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 e…

I think it's the same compulsion that makes many (though not all) people who get a PhD feel like they have to mention that fact everywhere (e.g. Dr. John Doe, Ph.D.).

Re: Absolute truths I unlearned as junior developer

#279

Post by neetodavid »

drbojingle wrote: post #240
taneq wrote: 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…

I agree with you but I can't bear to say code doesn't matter. Try not writing any and see how valuable software is without it. Better yet, delete it and see what happens :D. I expect Codeless will become a thing one day but, until that day comes you will write code, because the code is necessary and I have trouble saying that the code is needed but also doesn't matter. Least important necessity maybe?

I've read on this website about people launching minimum viable products that appear to the customer to be some kind of automated service that in reality are the owner manually satisfying the order.

The software isn't necessarily what the customer values. You can provide a valuable service with 0 LOC

Re: Absolute truths I unlearned as junior developer

#280

Post by justbaker »

beat wrote: 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.

I can't speak enough on this one. In our craft, The better one is at communication skills, the more effective their technical skills will be.

Post reply on HN