Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#471

Post by thaumasiotes » Sat, Jun 08, 2019, 5:25 AM UTC

pjscott wrote: post #359

taneq wrote: post #249

Earlier quoted context omitted.

...you don't remember what you were doing 6 months ago? I'm sorry, that's still not a good excuse. Maybe you don't remember every tiny facet but hopefully you'd have a general idea. And above all that, if you're a senior dev then you'd understand that "this code is unfamiliar" does NOT mean "this code is bad." I mean really, "this code is unfamiliar therefore it's messy therefore we should rewrite it" is a flaming re…

One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there. One of my biggest frustrations is that so many people don't bother, even when it would literally be just one little sentence.

> One of my favorite things about comments in programming is that you can stick a label on that fence explaining why it's there.

This is routine for ordinary cultural practices as well. However, the common explanation for a given cultural practice usually has nothing to do with the actual reasons it might be a good idea.

Re: Absolute truths I unlearned as junior developer

#472

Post by rags2riches » Sat, Jun 08, 2019, 5:48 AM UTC

pfranz wrote: post #355

eitland wrote: post #324

Earlier quoted context omitted.

Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.

It drives me nuts when you find a forum post and they never reported back. Or it's a terse "I figured it out." I try really hard not to do that for internal or public forums. The odds are better than you think that you'll stumble on the same topic a few years from now.

Wisdom of the Ancients

https://xkcd.com/979/

Re: Absolute truths I unlearned as junior developer

#473

Post by jdsully » Sat, Jun 08, 2019, 6:03 AM UTC

mgkimsal wrote: post #457

jdsully wrote: post #346

Earlier quoted context omitted.

Here we get to the real heart of the problem. Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture. But the wrong lesson seems to be taken away from this. It’s not that all code is shit - it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.

> Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture. several projects I've come in to - yeah, the code what shit, and yeah, I could do better. And I've done better. By asking questions, documenting the answers, writing sample data, and writing tests. I get that code can be sloppy, have edge cases, etc.…

Oh absolutely code can be shit. But I’ve also seen code that’s made the company millions of dollars and run flawlessly for 20 years be called “shit” because it doesn’t look like modern code. The replacement naturally consumes many times more resources and has bugs that were long fixed in the old code.

In my experience the latter case is far more common. But I suppose experiences will differ dramatically depending on what you work on.

Re: Absolute truths I unlearned as junior developer

#474

Post by Too » Sat, Jun 08, 2019, 6:39 AM UTC

docker_up wrote: post #67

Overall a good article, but I completely disagree with the notion that "good enough is good enough". I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast. I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" beca…

It's also a matter of dealing with the problem now while it's right in front of your eyes and you remember.

Generalizing here but assume 6 months later this rare duplicate happens for a very important customer so you can't just brush it off, you now really have to fix it. By then nobody remembers this code review so you don't even know if this duplicate is a one off rare event or if it is going to affect all customers. Fixing it in code review might have taken a few hours extra for one guy, now you sent the whole team scrambling weekend overtime just to find the issue and understand the implications.

Re: Absolute truths I unlearned as junior developer

#475

Post by mads_ravn » Sat, Jun 08, 2019, 7:10 AM UTC

ben509 wrote: post #196

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.

Also related: > Understood as senior: Communication skills matter most. The reason people dismiss comments is usually that they or others around them aren't good at writing useful comments. Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing." Yes, those are pointless. Often what's going on is a person is dumpin…

> Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing."

I actually think those comments are useful in two ways:

1. The process of writing a comment will help often help me rename the function/variables so e.g. “defines a function that opens thing” becomes something like “opens can_of_worms with the given instrument and restraints” for the method definition open_can_of_worms(instrument, restraints)

2. You can use variable/return value comments to further restrict the domain of values, e.g. non-null, positive or in the range 1-42 (arguably it would be better to express some of these in the type system, but that is a different discussion). These comments show up in my IDE when I try to call the code in a remote location, so I don’t have to guess or remember the constraints.

(edit formatting)

Re: Absolute truths I unlearned as junior developer

#476

Post by apersona » Sat, Jun 08, 2019, 7:15 AM UTC

munmaek wrote: post #470

wltprgm wrote: post #404

Earlier quoted context omitted.

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

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

I think you're misinterpreting the intention of the title of "Professional Engineer". As far as I can tell, it's for accountability for public projects (buildings, power, etc.). It's not strictly limiting what job titles can have the word "engineer" in it.

Most engineers in the aerospace industry don't even take the FE exam. Would you refuse to call most aerospace engineers "engineers" then?

Re: Absolute truths I unlearned as junior developer

#477

Post by world32 » Sat, Jun 08, 2019, 7:30 AM UTC

vmurthy wrote: post #146

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…

Perfecto! As a programmer turned product manager, I see this first hand every single day. The end user doesn’t care what technology you use as long as it solves their problem(s). My managers don’t care what technology my team uses as long as timelines and budgets are met. I’m astonished and sometimes smile at how my old programmer self wouldn’t understand this basic fact.

You're right that the end user doesn't care about what technology you use, but do they care about things not working? Do they care that a new feature takes 3 months to develop when it could have taken 1 month if the code had been better architected?

Its funny to see management types dismiss the programmers as being "airy-fairy" when they talk about things like code quality and technology stacks but then they wonder why things get completed on time, why bugs happen, why sites get hacked etc.

Somebody else has mentioned this analogy before in this thread, but if you had a house built would you say the same thing about the structural integrity? "As long as the floor can support me then thats all that matters", "House dwellers don't care what kind of structural beams are used to support the floor they just want it to not collapse". That kind of a mentality is ok for an average person living in a house but you'd you have to be off your rocker to hire a building manager who said that.

Re: Absolute truths I unlearned as junior developer

#478

Post by larkeith » Sat, Jun 08, 2019, 7:43 AM UTC

fouc wrote: post #446

tehlike wrote: post #412

Earlier quoted context omitted.

> git stash # i might need this one day And i never need it.

I've started saving my stashes to branches instead.. adding a _ on the front of the branch name to remind me to delete the branch at some point

Out of curiosity, do you ever actually delete the branches? I would absolutely just end up with a number of _-prefixed branches on all my projects.

Re: Absolute truths I unlearned as junior developer

#479

Post by wltprgm » Sat, Jun 08, 2019, 7:47 AM UTC

munmaek wrote: post #470

wltprgm wrote: post #404

Earlier quoted context omitted.

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

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

Nobody said that you are software engineer, you can just call yourself whatever you want

Those who called themselves software engineers are indeed software engineers, no one can forbids it

Fancy term like engineer is for marketing purposes, just like you said it's prestigious, they use it because they want to impress people, anything wrong with that? No, it's correct.

And it's also correct if anyone think they don't fit the title engineer, because it's his/her opinion which the software engineers won't likely give a fuck.

No one can stop them from using the term.

As for the Canada's law, the earth is bigger than that AFAIK. China and US software engineers are waiting for arrest. Except for Texas FYI

Standardization/basic practices mean shits by the way, it's research and development phases during engineering, people can invent what they want in their own ways as long as their products are legit

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.

Wikipedia can be sue at anytime, as you like

Re: Absolute truths I unlearned as junior developer

#480

Post by randyrand » Sat, Jun 08, 2019, 7:57 AM UTC

SamuelAdams wrote: post #97

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

Variable names can also go stale - you should consider replacing all the variable names with placeholders. /s

Deleting all the comments is too far in the extreme. How about just read them and realize they could be stale?