Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#131

Post by templ123213 » Fri, Jun 07, 2019, 3:40 PM UTC

typon wrote: post #87

One thing I would say about the whole "good enough is good enough" mentality is that if everyone has that mentality in a company, your code quality will decline so far that it will be impossible to get anything done in the future. This has happened to my company because ten years ago people had this mentality and it did work for them, getting us a lot of market share and short term success due to high profit margin.…

I think she covered that by mentioning that architecture is more important as a senior developer. My understanding as a senior developer by what she means is not to focus on optimizing the hell out of code. Too often, people would demand others use the most optimize piece of code, but if the code is only going to be called once or twice, you should focus your time on other things more important.

I think your company is suffering from bad architecture design more than anything else. It seems like everything is tightly coupled with little room for modifications. This probably means those senior developers weren't really senior to begin with. This tends to happen at startups where business is prioritized and people get hired with inflated titles. I have seen that happen in a lot of startups.

Re: Absolute truths I unlearned as junior developer

#132

Post by alexhutcheson » Fri, Jun 07, 2019, 3:40 PM UTC

Multiple of these points could be grouped under the general belief that "Everything is equally important". The #1 change required for growing into a senior role is to form a habit of ruthless prioritization of how you spend your time (and your team's time, if applicable).

Often you end up in situations where all of the following are true:

1. Your teammate or colleague is designing or implementing something.

2. You have different ideas about how that thing should be done.

3. Your ideas would produce an objectively better system.

4. Even though (3) is true, the improvement to the system or design isn't worth the cost in your time, team velocity, team morale/development, etc.

In that case, the right move is not to intervene, and to let your teammate design/implement the system their way. This is hard to do, because most engineers are natural maximizers[1], but for most tasks you're much better off with a satisficing[2] approach. This isn't to say that you should never give feedback on designs or in code reviews - you absolutely should, but always remember that you have a limited budget for your own time and for team morale, and you should spend that budget on the feedback where it will make the biggest difference.

[1] https://en.wikipedia.org/wiki/Maximization_(psychology)

[2] https://en.wikipedia.org/wiki/Satisficing

Re: Absolute truths I unlearned as junior developer

#133

Post by JustSomeNobody » Fri, Jun 07, 2019, 3:40 PM UTC

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…

> Learned as junior: New tech solves old problems.

> Understood as senior: New tech creates new problems.

This is one all the people who push "new and shiny" need to learn.

Re: Absolute truths I unlearned as junior developer

#134

Post by brianmcc » Fri, Jun 07, 2019, 3:41 PM 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…

There's the "it'll do" mean of "good enough", which really isn't good enough. Then there's the "of sufficient quality" meaning, which is by definition good enough. The latter is the true minimum bar, IMO, and what I believe the author means?

Re: Absolute truths I unlearned as junior developer

#135

Post by mixmastamyk » Fri, Jun 07, 2019, 3:41 PM UTC

ramraj07 wrote: post #84

jayd16 wrote: post #63

Earlier quoted context omitted.

Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping). How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At…

I still struggle to understand the real benefit of unit tests; the most intuitive tests that test real business logic that I've written always become something like semi-integration tests. Pure unit tests that test a small isolated function are almost never useful to catch bugs after they're written. The only legitimate use for them has been that it's easier to understand the purpose of the function and edge cases. A…

The benefit is being able to make changes and sleep soundly at night.

I agree with the grandparent that they are more useful as a project matures rather than the design stage. Starting small and adding tests as designs solidify is a good tradeoff.

Re: Absolute truths I unlearned as junior developer

#136

Post by onion2k » Fri, Jun 07, 2019, 3:41 PM UTC

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…

People in fields where they write code that has to be proven can still know when it's appropriate to write bad hacky code. If they believe "I write proven code for my EHR system therefore all code must be like that." I would argue they're not pros.

Being a professional is knowing how to do your job well. Applying a single heuristic to every problem isn't that.

Re: Absolute truths I unlearned as junior developer

#137

Post by cuddlecake » Fri, Jun 07, 2019, 3:42 PM UTC

jasonhansel wrote: post #29

I think another truth to unlearn is "users know what they want, and can express what they want in precise technical terms."

And the complementary truth would be "I know what the user wants".

My team and I are kind of trying to break this up, since we suffer from this a lot.

Re: Absolute truths I unlearned as junior developer

#138

Post by kps » Fri, Jun 07, 2019, 3:42 PM UTC

leibnitz27 wrote: post #39

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…

Way back in the day, my boss made a lovely observation - 'write your code like it's going to be maintained by an axe murderer who has your home address, and nothing to lose.' Simple guidelines to live your life by ;)

Attribution: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John F Woods, 1991 in comp.lang.c++¹

(I do not know who first replied, ‘I do know where I live.’)

¹ https://groups.google.com/forum/#!msg/comp.lang.c++/rYCO5yn4...

Re: Absolute truths I unlearned as junior developer

#139

Post by busterarm » Fri, Jun 07, 2019, 3:42 PM UTC

himynameisdom wrote: post #107

i think now more than ever, there needs to be a bridge mindset between technical and non-technical. i learned that very early on, and even spent some time in a customer-facing, non-technical role to hone my bridge mindset. the ability to have empathy for the end user, and everyone else upstream who will touch your logic, is paramount and takes care of a lot of issues. it's up to us as technical professionals to care…

Some of us technical people like to be client-facing. The key is to make room for us to do that. Let us handle the client/user and then take meetings with us so we can filter what's appropriate to you.

The biggest problem with "technical people" is the desire to retreat to a pair of headphones and not communicate with anyone all day. Set aside some consistent portion of your day where that's the only time you'll take meetings and we'll work around your schedule.

Re: Absolute truths I unlearned as junior developer

#140

Post by technomalogical » Fri, Jun 07, 2019, 3:42 PM UTC

BurningFrog wrote: post #105

snazz wrote: post #48

Earlier quoted context omitted.

This is true with basically everything. Game development attracts more than its fair share of truly horrid code, to the point where success seems almost inversely correlated to code quality. If you decompile Terraria (using CIL, which preserves the object design), for instance, you'll notice that its main class is over 40kLOC and that basically all of the business logic is encoded in one great big chain of if-stateme…

Maybe games can get away with more things because when they're done, they're (often) DONE . There is no next release, maintenance, new features etc. Once Balloon Pirates is done it ships, and is never touched again.

I don't think that's been the case for a long, long time. Almost every new game on modern consoles and PCs will see one (or many) updates in its lifetime. Game cartridges, things we used to think of as immutable, are merely storage devices for delivery of the original game code. Two recent games I purchased for the Nintendo Switch, on cartridge, both required a download before I could play them.