A bunch of programming advice I'd give to myself 15 years ago • Hacker News Board

Re: A bunch of programming advice I'd give to myself 15 years ago

#81

Post by spoiler » Sat, Jun 29, 2024, 2:19 PM UTC

cm2187 wrote: post #36

BiteCode_dev wrote: post #3

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

A way to rephrase your point about complexity is this wonderful quote " Developers are drawn to complexity like moths to a flame, often with the same outcome " (Neal Ford)

I've experienced this too, but I never understood why this phenomenon happens.

Is it because we start adding abstractions before we understand the problems?

Like, there's a certain threshold where keep things too simple makes them too complex, so people start introducing abstractions to reduce complexity. But often it's the wrong abstractions and then we accidentally end up with worse complexity that's harder to unravel.

There must be a term for this waves hand thing?

Edit: gosh typical on phones is hard

Re: A bunch of programming advice I'd give to myself 15 years ago

#82

Post by BiteCode_dev » Sat, Jun 29, 2024, 2:20 PM UTC

rileymat2 wrote: post #27

ourmandave wrote: post #20

Earlier quoted context omitted.

Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. You'll reach the level you want to avoid doing all this. What if future you has reached that level and people on your team are shipping spaghetti?

I feel like this is bad advice, really, you need to be obsessed with quality and growth, but you can't let that stop you from shipping. Try for clean to the best of your ability in the time constraints you have, but accept that it will be dirty.

Obsession will stop you from shipping.

Or it's not an obsession.

It's caring.

Very few people can pull off a Steve Job level of nitpicking and actually finish a project.

I certainly couldn't, and that advice is for young me.

Re: A bunch of programming advice I'd give to myself 15 years ago

#83

Post by pavel_lishin » Sat, Jun 29, 2024, 2:21 PM UTC

vitus wrote: post #73

The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is "When working on a team, you should usually ask the question". Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an a…

On the other hand, though, I really wish people would take at least ten minutes to do that digging through the code or reading through the documentation before asking.

One, reading code in general is a good thing to do when you're new, and it's a skill that should be built up in general.

Two, you might actually find what you're looking for, and answer your own question! It's a nice little boost to realize you're getting self-sufficient.

Three, you'll have a lot more context for me, which will make it easier for me to give you the answer. "Hey, how come this function doesn't return what I expected" is a much harder question to answer than "This function says it returns a list of items a user has accessed in a given workspace, but it's returning an empty list; I've checked my local database and it has a good set of seed data I think, and from looking at the function there's nothing obviously filtering out users, so what's going on?"

Re: A bunch of programming advice I'd give to myself 15 years ago

#84

Post by supriyo-biswas » Sat, Jun 29, 2024, 2:22 PM UTC

I wish more articles talked about the usefulness of integration tests over unit tests. Personally, I feel that unit tests are overrated and rarely give the required confidence to inform the team whether something is ship ready, whereas integration tests on the common workflows means that even when a bug is introduced, very few users are affected.

Re: A bunch of programming advice I'd give to myself 15 years ago

#85

Post by BiteCode_dev » Sat, Jun 29, 2024, 2:24 PM UTC

Zenzero wrote: post #66

BiteCode_dev wrote: post #3

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

> It's ok, doctors hurt people for years while learning to save them. Modern medical education doesn't work this way.

Yeah, I'm surrounded with medical professionals.

It totally does.

They make grave mistakes all the time. And they hide them. They lie about them.

They have their ego and career on the line.

And they don't have enough resources at their disposal, not enough hours, too many patients, and they are exhausted.

In short, they are humans in a human system.

Re: A bunch of programming advice I'd give to myself 15 years ago

#86

Post by mgkimsal » Sat, Jun 29, 2024, 2:24 PM UTC

FLT8 wrote: post #21

graypegg wrote: post #4

Earlier quoted context omitted.

A bit snarky, but I would add - don’t read opinions from a list and take it as gospel. Adapt to the jobs you’re in, and you’ll develop your own opinions, but now with experience to explain why. Opinions are formed by getting repeatedly hit with the consequences of your (and other’s) decisions, and everyone just has to take enough hits till the pattern seeking area of your brain takes over.

Maybe add to that: try to stay long enough in a role to really feel the consequences of your actions. Even better if you're on pager for a while too. I know it's not trendy to stay in a job for long these days, and conventional wisdom is it's not great for your salary either, but one thing it will do is allow you to understand whether decisions you made were actually good or not. There are roles I've been in where it…

I've been called back to code long after I left an org, and have had to review my own code 10-12-15 years after the fact. Seeing both the positive and negative aspects of decisions having played out in the real world was something it's hard to get from reading, and I'd argue somewhat harder to get even if you stay inside the same org for that length of time. Staying on the inside, you'll rationalize a lot of the changes to the code, the team and org over time, and it may be harder to be more objective about the impact the code has had.

I was quite proud of some decisions, but realized the negative long term impact of others. Trying to share that experience and whatever 'wisdom' or 'lessons learned' with others has been its own challenge in some situations, because you can easily come across as "the old person" who doesn't "get it" wrt to current trends. Some issues are evergreen and fundamental, but it's difficult for less experienced people to understand why some of these things are really core. I'm not sure there's much substitute for experience in many cases.

Re: A bunch of programming advice I'd give to myself 15 years ago

#87

Post by BiteCode_dev » Sat, Jun 29, 2024, 2:26 PM UTC

johnisgood wrote: post #9

BiteCode_dev wrote: post #3

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

I have a very severe case of impostor syndrome. :(

You probably are. But most of your colleagues as well :)

Most adults are kids in big meat suits, they fake it a lot.

I started to live like I was not completely worthless at 35.

Not saying that to be proud of it, just stating that if you think humanity should do better, the first person you'll judge is you.

It will be glaringly obvious you are not meeting your own standards.

The higher your standard, the longer it will take for you to reach them.

And the way to get there faster is to ignore the shame, and do it anyway. Because if you don't, your growth will be slower, and you will do more damage for longer.

Real life means real consequences.

It will make you more tolerant of others as well. Way more tolerant.

Re: A bunch of programming advice I'd give to myself 15 years ago

#88

Post by valyala » Sat, Jun 29, 2024, 2:27 PM UTC

My advices to new software engineers:

- Always think how to simplify the code you write, since simple code is easier to maintain and debug.

- Prefer writing dumb code than smart code. Smart code is good for programming contests. Smart code is very bad in production when it needs to be debugged or refactored.

- Always think about improving the usability of the software product you work on. Users don't care about code. They care about UX of your product.

- Fix small usability issues as soon as you notice them, since these issues are usually the most annoying for end users.

- Do not start writing code with some popular design patterns. Just write the most simple code, which resolves the given task. Later, the best design patterns will evolve organically from the code solving the particular task.

VictoriaMetrics development goals are based on these rules - https://docs.victoriametrics.com/goals/

Re: A bunch of programming advice I'd give to myself 15 years ago

#89

Post by neilv » Sat, Jun 29, 2024, 2:30 PM UTC

BiteCode_dev wrote: post #3

Those are way too abstract advice when you start programming. You can only understand them because you lived those situations, which implies experience you don't have. I would say (specifically to my young self): - There is no substitute for doing. Less tutorials, more coding. - Stop being obsessed with quality: you are not at the level where you can provide it yet. Do dirty. Do badly. But ship. Some people will be m…

> Doing something for the hell of it is worth it. Just make it separate from the point above so they don't conflict.

This is a great use for new, standalone open source modules: feel free to experiment with styles or techniques or goals that you wouldn't want to justify. (Or for experiments that you start and then abandon without ever showing anyone.)

For example, when I was making lots of packages to help build out the Racket ecosystem, I'd already made an HTML-writing package, but I felt a craving to do one that used syntax extension at compile time, rather than dynamic s-expressions. So I just did it, as a separate package: https://www.neilvandyke.org/racket/html-template/

I don't recall anyone saying they saw value in it, but I like it, and I scratched that itch, and added another skill to my programming mental bag of tricks.

Re: A bunch of programming advice I'd give to myself 15 years ago

#90

Post by liampulles » Sat, Jun 29, 2024, 2:32 PM UTC

pavel_lishin wrote: post #83

vitus wrote: post #73

The point that resonated most with me, and that I repeat every time someone early in their career asks for advice (or one thing I wish I had been told when I first started out) is "When working on a team, you should usually ask the question". Early in my career, I spent a lot of time reading unclear or obsolete documentation, poring over code, etc, when I could have asked the person sitting next to me and gotten an a…

On the other hand, though, I really wish people would take at least ten minutes to do that digging through the code or reading through the documentation before asking. One, reading code in general is a good thing to do when you're new, and it's a skill that should be built up in general. Two, you might actually find what you're looking for, and answer your own question! It's a nice little boost to realize you're gett…

At my first job, at a consulting company, they had a good rule, which was basically "show initiative when asking questions". What this boils down to is if you ask how to do X, you should first research and think about it, and then you can say "I think Y is how I do X, am I on the right track?"

A lot of the time, you'll answer your own question getting to Y. If not, it will save the person you're asking a bit of legwork, and show you are not trying to have them do your job for them and have respect for their time.