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

81–90 of 534 posts

Re: Absolute truths I unlearned as junior developer

#81

Post by kemiller2002 »

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…

I understand what you are saying. I think what she's really referring to is: The perfect is the enemy of the good. You have to adhere to certain level of standards, but at some point you do have to admit there is a difference between, "this has problems", and "it's not how I would have done it, but it works and is more or less OK."

Re: Absolute truths I unlearned as junior developer

#82

Post by rorykoehler »

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…

You're spot on. Regarding your last point though my interpretation of the blockchain hype was that the problem of the business was that they needed quick and easy money. Blockchain investors solved that.

Re: Absolute truths I unlearned as junior developer

#84

Post by ramraj07 »

jayd16 wrote: post #63
lukejduncan wrote: post #11

"Loads of companies and startups have little or no tests" which should scare you, or at least it would scare me if I joined a team. You can definitely over test, but how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? There's a trade-off with testing. Early in the dev cycle, not testing can make you go super fast (supposedly, this hasn't been my p…

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. At times it makes me think about edge cases and identify bugs WHIlE writing the tests, but once they're written, they're never useful unless someones actively trying to understand that exact unit of code.

Re: Absolute truths I unlearned as junior developer

#85

Post by RussianCow »

dahart wrote: post #34
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…

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

Re: Absolute truths I unlearned as junior developer

#86

Post by archagon »

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…

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.

Re: Absolute truths I unlearned as junior developer

#87

Post by typon »

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. However, today we are suffering immensely due to those decisions, losing customers and new hires because no one can get anything done except put out fires due to critical customer issues.

I think a healthy mix of idealists and realists is necessary.. With senior developers representing a good majority of the former.

Re: Absolute truths I unlearned as junior developer

#88

Post by patagonia »

onion2k wrote: post #53
patagonia wrote: post #47

Earlier quoted context omitted.

This bothers me. As code continues to eat the world, this is akin to saying “building codes don’t matter”. That is dangerous. And it isn’t professional.

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.

I never, ever, said “All code must be beautiful. I never even implied it. Unless there is some general agreement that I am unaware of among architects and builders that building codes exist to make building plans “beautiful”.

And about that implied ad hominem. It doesn’t matter if I’m a pro.

Building codes allow one to say whether plans conform or do not conform to code. That way you don’t have to be a “pro” to determine whether the plan is up to code. You compare the plan to the code. You didn’t write the code. You don’t need to think the code describes beautiful plans. You just compare.

Re: Absolute truths I unlearned as junior developer

#89

Post by pdpi »

chessturk wrote: post #70
bdcravens wrote: post #26

Earlier quoted context omitted.

Debt (technical and otherwise) is leverage if utilized well, and potentially crippling if abused.

I knew a shop that refused to move its customer data out of an ancient MS Access instance until one day it just started shedding records. That's what I think of when I hear technical debt. What are examples that make sense and don't just explode in your face?

Whatever it is you're writing doesn't have to work for the next twenty years. If it's sufficiently simpler and cheaper, it's fine if that project only works for the next five years, and you have to start working on a rewrite in four. By then, you'll either have gone broke (in which case the extra scaling would've been useless anyhow), or you'll have four more years of experience to guide you in how to build the next generation.

In your particular case, that MS Access DB was almost certainly the right choice when it was written, and the gotcha in that story is that they didn't start planning the migration away from Access until it was too late — effectively, they didn't pay off the tech debt when they should have, and got foreclosed on.

Re: Absolute truths I unlearned as junior developer

#90

Post by docker_up »

mlent wrote: post #78
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…

Hey! OP here. I definitely don't mean "good enough is good enough" as an excuse -- pushing for quality is extremely important. My point was more about nitpicking line by line for perfection. What you're talking about sounds like a legitimate performance issue. I think we're on the same page, but maybe my point wasn't clear enough. I tried to make it clear in my last point that "code is quality is important" but it's…

When I code review, I differentiate between "code quality" and "opinion". First off, there needs to be a coding standard guideline so that 80% of all issues of "opinion" vs "coding standard" are well defined. This is one of the reasons why I like go, because things like go fmt are the great equalizer.

I probably won't like the variable names people chose but I won't comment on that because that's "my opinion". I will comment on even the smallest bug I see, because that's what we're paid to do. So line by line "perfection" is what I believe we need to strive for in terms of code quality. Maybe not so much "perfection" but "best practices" might be a better way of stating it. We always need to strive for best practices so that our code is predictably easy to maintain, read, etc.

Post reply on HN