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

401–410 of 534 posts

Re: Absolute truths I unlearned as junior developer

#401

Post by tigershark »

RussianCow wrote: post #85
dahart wrote: post #34

Earlier quoted context omitted.

Oh this is such a good comment! > Legacy code that I wrote myself is hard to read. Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of 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…

> 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!)

It always happens to me while I approve my own pull requests to master.. :’(

Re: Absolute truths I unlearned as junior developer

#402

Post by [deleted] »

criley2 wrote: post #73
onion2k wrote: 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.

>If you think "All code must be perfect" then you're not a pro yet Or they're a pro in a very different field than you. When I worked in web development, I was gobsmacked at what professionals considered "good enough to ship". Now that I work in Medical EHR, the standards for 'good enough to ship' when lives could be on the line is very, very, very different. I imagine a NASA engineer creating famously low-defect cod…

[deleted]

Re: Absolute truths I unlearned as junior developer

#403

Post by chimpburger »

criley2 wrote: post #73
onion2k wrote: 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.

>If you think "All code must be perfect" then you're not a pro yet Or they're a pro in a very different field than you. When I worked in web development, I was gobsmacked at what professionals considered "good enough to ship". Now that I work in Medical EHR, the standards for 'good enough to ship' when lives could be on the line is very, very, very different. I imagine a NASA engineer creating famously low-defect cod…

That's the point. The context of the code matters. 99% of code is not critical to life. Applying NASA level of rigor to every line of code ever written is an indication of mental disorder (autistic obsession)

Re: Absolute truths I unlearned as junior developer

#404

Post by wltprgm »

munmaek wrote: post #274
pdpi wrote: post #120

Earlier quoted context omitted.

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

it's fair to say that if you don't like it, then don't speak about it

that's your definition of engineering, or whatever officials that define it

more so, who cares about your skills other than your employer? And your employer cares about your skills, why should he care about your title?

even if other programmers who like to address themselves as software engineers, is it up to you to decide whether they can be hired?

It's just a title for god's sake

Re: Absolute truths I unlearned as junior developer

#405

Post by gmueckl »

Macha wrote: post #276
gmueckl wrote: post #243

Earlier quoted context omitted.

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

Yes, but blame puts the focus too much on the authors instead of the changes themselves. I also use it to understand how code evolved over time, but only in circumstances where I suspect the history to hold import clues.

Pinning bad work on a person does not make progress. Fixing bad code does.

Re: Absolute truths I unlearned as junior developer

#406

Post by vortico »

wan23 wrote: post #234
vortico wrote: post #61

Perhaps the reason for "nobody writes tests" in the real-world isn't primarily because of time/cost, but because virtually no real potential bugs are testable. If you're writing a JPEG encoder or database model handler, yes, you can test that all day, but those things already exist and are well-tested for you. But if you're designing retail software or a web app, there are 2^10000 things that can go wrong, so most co…

This is all wrong. When you have enough people working on a codebase such that not everyone knows everything about it, tests are a great way to document the behavior. They're much better than something like a wiki, in fact, because nobody actually keeps that kind of documentation up to date.

I'm not arguing that tests are useless. I'm arguing that tests are usually impossible. I invite you to suggest a test for https://github.com/VCVRack/Rack for example that could either 1) have prevented a bug, or 2) document the software's behavior.

Re: Absolute truths I unlearned as junior developer

#407

Post by james_s_tayler »

HeyLaughingBoy wrote: post #343
snicky wrote: post #187

Earlier quoted context omitted.

Semi-related story of mine: 1. Stumble upon some specific problem with a web framework we use. 2. Jump straight to stackoverflow. 3. Sbd had a similar issue, nice. 4. Sbd wrote a very concise answer, nice too. 5. There's my nickname under the answer. Oh, wait...

THANK YOU!!! I really thought this only happened to me :-)

Have experienced this too. Haha.

Re: Absolute truths I unlearned as junior developer

#408

Post by chimpburger »

cntlzw wrote: post #75
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…

True. Oh man, I was so angry about that. You read all them books, refactor anything, use that functional programming, but in the end: who cares! A shiny new button gets more attention than you refactoring that SQL statement.

If you get away from frontend fluff and work on serious backend systems involving large financial transactions, they will appreciate those more advanced engineering skills and disciplines.

Re: Absolute truths I unlearned as junior developer

#410

Post by wltprgm »

pdpi wrote: post #74
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…

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…

this topic never stops, trust me

it's time for you guys to realize this effect from calling yourself "coders"/"programmers"/"problem solvers" are nothing but marketing

It's just to impress those who don't know otherwise

Post reply on HN