Hacker News new | past | comments | ask | show | jobs | submit login

> seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago.

What classes as 'senior' that their own coding style has changed that much in 6 months? O.o

> I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code.

Good dev. Remember, you are not your audience. Unless you're just writing play-code in which case go nuts and be as 'clever' as you want. :D

> When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky.

Then they're wrong, and tbh that's not something I'd accept more than once from an employee.




> > seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago.

> What classes as 'senior' that their own coding style has changed that much in 6 months? O.o

Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then, and that at the time you focused too much on the writing, not on the reading.


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. Took over a project that was halfway migrated from CI to Laravel. The migrator had close to a year on this 'migration'. We had not one unit test case, no migrations, no seeders, no integration tests when we took over. What we had was piles of half-baked uncommented model code, over-reliance on magic methods, Laravel/CI models with the same names and method names often being used in the same request but with unintentionally dissimilar behavior.

The 'code' isn't the (whole) problem. All the other stuff around the code that provides the context is the problem. We had ~ 20 tickets in a tracking system with vague notes, and were given 5 email threads of discussion about functionality questions, none with actual resolution.

> it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.

Or... the person writing it before you simply didn't know how to write/document.

Sometimes - really, honestly - you can actually "do it better" because... really, honestly, sometimes you are actually better - more competent, more experienced, more diligent, more professional - than the person who left the code you're working on. Not always, but not never.


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.


I'd meant to add that part as well too - code can be bad and still work, and work OK. The problems only come in when it needs to be changed.

I've advised a number of folks to care less about the code style, and focus more on making it at least understandable. I don't particularly care if you're using a factory pattern or not, but please do doc/comment someplace what the expected behavior for your 'backordering' logic is. I can fix things later if I understand what was intended, vs just what I have to guess at later.

Have worked on some projects in the last few years that are 'bad' from code perspective. One is bad, but the company as a whole operates... decently, and is improving, and more importantly, is providing a lot of value to their customers. The customers tolerate some bugs now and then because a) they still get value and b) the issues are addressed. There's a full process for changes/fixes/rollouts, and the team overall understands that there's tech debt to deal with. Some folks understand that they're still paying off tech debt from 3-4 years ago, and understand those decisions were bad, and try to avoid those same mistakes.

Hundreds of integration and unit tests (growing every week) help grow the confidence levels, and remove barriers to smaller refactoring efforts, because there's a reasonable way to detect the impact of changes. It's not perfect, but that's also understood and accepted.

Another one is the CI/Laravel situation from above. Small company, no real 'tech' people on staff - it's all 'outsourced'. They're frustrated because they see other companies progressing faster than they do, and everything seems to take 5x longer than they expect. It's because the code is bad (on many levels). If we were not trying to make any changes, and it just ran in its current state, it would still continue to make money for them, but they want new features, which requires actually understanding how everything fits together. It took two people several months to have a reasonable understanding of how all the running parts fit together (while also trying to add new features/etc), and finally get a small number of unit tests in place.


...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 red flag. Chesterton's fence, people!


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.


Unknown unknowns.

My coding style hasn't really changed in years - frankly, I don't write a lot of code, I do other things. But I often run into situations where I'm irritated at my own bad code from months earlier, when the shortcomings of the code are actually driven by things I know now that I didn't know then.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: