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

461–470 of 534 posts

Re: Absolute truths I unlearned as junior developer

#461

Post by njharman »

lmm wrote: post #111
docker_up wrote: post #72

Earlier 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.

Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.

(as others have pointed out here and every where) Comments are NOT for making code understandable. The things you mentioned are for that.

Comments are for things like

1) explaining why this thing that looks wrong or dumb, really isn't. 2) explaining what method/function/class/whatever is suppose to do. Because code can be correct, understandable, and still wrong.

Re: Absolute truths I unlearned as junior developer

#462

Post by Buge »

snicky wrote: post #187
enobrev wrote: post #170

Earlier quoted context omitted.

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

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

Does "Sbd" stand for something, or is that your username?

Re: Absolute truths I unlearned as junior developer

#463

Post by [deleted] »

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…

[deleted]

Re: Absolute truths I unlearned as junior developer

#464

Post by joe_the_user »

enriquto wrote: post #205
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…

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

This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code.

I would claim that any clever final result can be accomplished without any need for intermediate cleverness. Things that look clever to other people but are intuitive to you might be OK. Things that look clever to you should be avoided when possible.

Re: Absolute truths I unlearned as junior developer

#465

Post by war1025 »

kbp wrote: post #378
Tade0 wrote: post #289

Earlier quoted context omitted.

Here's what happened to me(A) and a friend(B) from a former workplace of mine(open-source project): B: Take a look at this shit code that I found. A: Whoah, it really is shit. Blame it so that we can see what kind of genious is behind this. B: ... A: Well? B: Apparently you wrote and I reviewed/approved it.

The "who wrote this?" mentality is a trap that's good to avoid. Get comfortable with different ways of writing something that, while they might have different tradeoffs, accomplish the same thing, and try to see past that. Understand that most code wasn't written by anybody--lines 1 and 3 were written by Alice a year ago, line 2 was written by Bob 2 years ago, and line 4 was written by Alice yesterday. `git blame` is…

`git log -p` is vastly superior to `git blame` for determining why a file is the way it is.

Re: Absolute truths I unlearned as junior developer

#466

Post by taatparya »

Buge wrote: post #462
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...

Does "Sbd" stand for something, or is that your username?

Somebody

Re: Absolute truths I unlearned as junior developer

#467

Post by [deleted] »

Buge wrote: post #462
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...

Does "Sbd" stand for something, or is that your username?

[deleted]

Re: Absolute truths I unlearned as junior developer

#468

Post by taneq »

ghaff wrote: post #181
wbl wrote: post #153

Earlier quoted context omitted.

Not Texas iirc.

As I recall my days in the oil industry, "engineer" was one of the most overused titles. We used to joke about "mud engineers" (reps of the companies that sold the ingredients that made up drilling mud) being, in fact, "mud salesmen." (If you were being generous, they were technicians but they did mostly make recommendations and sell you stuff.)

Heh, on iron ore mine sites we have "hose technicians" whose job is to clean up any spillage with a high pressure hose. There are also jokes about "sanitation engineers" who clean the toilets.

Re: Absolute truths I unlearned as junior developer

#469

Post by iamleppert »

illvm wrote: post #318
iamleppert wrote: post #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"!

Who defines what "good enough" means? Is it basic functionality? What if that basic functionality contains security vulnerabilities? What if it is written in such a way that will cause potential, foreseeable problems down the road? What if it is written in such a way that it is only understandable to the author? What exactly is "good enough?"

I’ve found it’s far better to error on the side of speed and work pragmatically on features rather than trying to deliver perfection. That’s just me though. Nothing is going to be free of defect or perfectly secure.

Re: Absolute truths I unlearned as junior developer

#470

Post by munmaek »

wltprgm wrote: post #404
munmaek wrote: post #274

Earlier quoted context omitted.

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 fair to say that if you don't like it, then don't speak about it

I would like to see the status quo changed, which is why I do discuss it. Of course it's fair that I hold an opinion and discuss it. There is no obligation for you to respond if you disagree :-)

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

It's not my sole opinion:

> As with many other professions, the professional status and the actual practice of professional engineering is legally defined and protected by law in some jurisdictions. [3]

It's understood that if someone holds the title 'Engineer', they went through a certification process from a regulated body, traditionally. You can see this for example in countries and per state. [0] [1] [2]

> In Canada the designation "professional engineer" can only be used by licensed engineers and the practice of engineering is protected in law and strictly enforced in all provinces. [3]

In Canada (and I believe some states), it is illegal to sign off an email or other correspondence as a "Professional Engineer" if you're not actually licensed as such. [4]

---

> is it up to you to decide whether they can be hired?

When did I mention hiring? All I said was the term 'engineer' is loosely used in the software industry, and it has absolutely no standard around it.

> employer [...] why should he care about your title?

I wasn't talking about my employer at all. I only referenced skills because I was responding to a portion of the parent comment.

> It's just a title for god's sake

It isn't. How we frame something is very important in my opinion–just as important as the concept itself. [5] If it's "just a title", then people should have no problem calling themselves programmers or developers. However one can see that we call ourselves "engineers" because it sounds prestigious, despite the software industry being a total joke when it comes to standardization or even following basic modern practices consistently.

[0]: https://engineerscanada.ca/accreditation/about-accreditation

[1]: https://ncees.org/engineering/

[2]: https://www.ncbels.org/

[3]: https://en.wikipedia.org/wiki/Regulation_and_licensure_in_en...

[4]: http://www.occupationalhealthandsafetylaw.com/ontario-man-fi...

[5]: Consider for a moment the term "Global Warming" versus "Global Pollution Epidemic". I strongly believe if we had gone with the latter instead of the former, there would not have been pushback to the scale that we've seen. It certainly would have avoided the confusion of "oh, but this winter is so cold, global warming must be a hoax"! It also shifts the focus from an effect of pollution, to the pollution itself. This example is quite different than the software engineer/developer example, but I think it illustrates my point that how things are framed is very important.

We are not software engineers, and we won't be until regulatory bodies exist, and we develop codes of ethics.

Post reply on HN