Things we always remind ourselves while coding

https://changelog.com/posts/things-we-always-remind-ourselves-while-coding

by fagnerbrack • 3 years ago

59 51 3 years ago

changelog.com

philprx• 3 years ago

Excellent !

I learned some things. I'll consider making posters of this ;-)

ulizzle5• 3 years ago

“It’s ok to fail”

Yeah, right. Failing is what gets you fired. Basically it’s a collection of safe, saccharine little pseudo maxims supposed to make everyone feel better

I prefer the poster with the cat hanging on to the branch going “hang in there”

hkon• 3 years ago

Ok to fail is what you say to the competition.

marginalia_nu2• 3 years ago

Places that won't tolerate mistakes are arguably places you don't want to work anyway.

Huge management red flag for a bunch of reasons. It means people will start to tell their bosses what they want to hear. Instead of products you'll build a fractal of potemkin villages.

liquidpele• 3 years ago

Mmm, depends on what “failing” means. Everyone makes mistakes, some people seem to be mistakes themselves.

rewmie4• 3 years ago

Places that won't tolerate mistakes are arguably places you don't want to work anyway.

That's hardly helpful advice. You don't have recruiters telling job applicants that they do not tolerate mistakes. By definition, employees get no warning before being fired for making a mistake, which is hardly the situation for advice such as "you don't want to work there anyway". When that happens, all there is to do is gather all your stuff, rethink your life, and update your resume, and prepare to explain in the next job interview how your last job finished so abruptly. Neither of these steps is in your best interest.

atomicnumber3• 3 years ago

I have been at three different companies in my career and while I know that's not that many, I can only job hop so much and I have at this point simply given up on believing that a company with good culture can possibly exist. And if it does, it's only like 5 people tops and it'll break down if/when it tries to scale.

Every leader views his workers as replaceable feckless layabouts, front line managers are the designated whip-crackers with far too little actual power, middle managers are stressed out fear-driven creatures with both little real authority AND no whip to crack over the workers, and leaf-node workers are depressed tired cogs in a system that cares tremendously little about them and cares increasingly less about even pretending otherwise, especially post-layoffs.

And yet the software still needs to get written. I cope by just doing what I can, not trying to do anything the system doesn't support me in doing, and making as many friends as I can along the way. And putting my family first every single time.

financltravsty• 3 years ago

In a pit of despair, are we?

If you focus on the shit, life will be shit. Focus on what's in your control. Maybe not a lot is, but the little things are. What time you go to bed, what you eat, how you spend the little free time you may have. Take control of that first, then build off of it. Step by baby step, you'll crawl out of the abyss, and remember that you aren't resigned to eating shit the rest of your life.

WalterBright• 3 years ago

Not my experience at all at any of the software companies I've worked for.

ulizzle5• 3 years ago

That's a good description of modern software development. For any junior devs reading, this is the accurate presentation of the reality of software development for the most devs. There are exceptions, but they are either lucky and know it, lucky but with a superiority complex who think they have a monopoly on the truth, NPCs, or the usual gaggle of people who disagree with everything I post here anyway.

Think about it: How can JavaScript have so many innovations, yet practically no one has moved on from the scrum/kanban abomination in going on a decade? Perhaps more. Why

vore• 3 years ago

If you can dress your failure up as a success in some way to management, then you can totally avoid getting fired.

drekipus2• 3 years ago

I, and many other people I know, failed all the time; and we never got fired, we simply learned from it and moved on.

People who get fired are the ones who never learn, and have a shitty attitude about failure.

I know which camp I'd rather be in.

rewmie4• 3 years ago

I and many other people I know, failed all the time; and we never got fired, we simply learned from it and moved on.

How confident are you that your example isn't just survivorship bias?

I know people who failed and got fired. I know people who failed and were forced to resign. Where does your advice fit in the real world?

lioeters• 3 years ago

cat hanging on to the branch going “hang in there”

I saw an artist who did a parody of this poster that said, "Give up."

Izkata• 3 years ago

Frozen's Let It Go turned into Give Up after going through Google Translate too many times: https://www.youtube.com/watch?v=2bVAoVlFYf0

CM304• 3 years ago

Not in my experience. For one thing, this is usually what the peer review process, tests and QA team are there to fix. Almost everyone's work will have at least some things that need improvement/fixing before they can go live, but there's a process to make sure they don't go through into production without those fixes.

If the issue actually happens in production and say, a bank's payment API goes down that may be a different story, but even then I've usually seen the managers say it was a process issue rather than finding someone responsible and calling for their firing. Or as the old story goes, treating it like an expensive learning experience.

But eh, your mileage may vary.

ulizzle5• 3 years ago

I suppose you do have a monopoly on the truth.

salawat• 3 years ago

For one thing, this is usually what the peer review process, tests and QA team are there to fix.

The QA team are not your personal team of muckrakers. The more you treat them as such, the faster we burn out, because it's our job to say no, and saying no is a recipe for interpersonal disaster or attrition in an org, especially once management inevitably starts overriding the department consistently, regardless of the amount of risk that they end up taking on in spite of it.

winddude• 3 years ago

Where's big things easily forgotten? Ohh yea, in common libraries... auth system, email system... all the things I used to build from scratch... migration system...

chatmasta• 3 years ago

We build these things from scratch because of all the lessons we learned (mostly about not building them from scratch) the last time we built them from scratch. :)

eternityforest• 3 years ago

Definitely true, most of what I've learned building stuff from scratch has been about not building stuff from scratch.

For my own projects I generally think YA(aren't)GNI that original feature, but YA(re)GN(or at least want)I that framework instead of vanilla, or that declarative config tool, or those type Annotations, etc.

reqo• 3 years ago

I guess all of that can fit inside a prompt to an llm and still leave room for other input. Wonder if it would improve coding agents such as GPT Engineer?

CamperBob2• 3 years ago

"The solution to this problem will not be found on Hacker News"

taneq• 3 years ago

This one time I got told off for reading Slashdot at work. The next day our tech lead couldn't figure out why the log files didn't contain anything recent after our control program crashed (which tripped a watchdog timer and hard-reset the controller). I got to explain how I learned from a Slashdot post that ext4 caches writes in RAM and can lose data if power is removed unexpectedly. That was a good day.

RandyRanderson• 3 years ago

"It's later than you think" is all you really need.

BitsOfBeard• 3 years ago

Mine is "Sustenance is actually beneficial to the coding"

bavell• 3 years ago

"Just because you can doesn't mean you should!"

bazoom42• 3 years ago

When I get stuck I use “what is the simplest thing that could possibly work?”

GoToRO• 3 years ago

Current day (definitely not modern) management is toxic.

The actual productive devs are seen as a threat and so on.

These things have a much bigger impact on yourself than if you take enough breaks or not.

sakesun• 3 years ago

Very good list.

ivanjermakov• 3 years ago

Clean up your damn editor tabs

Oh man, visual tabs is a productivity killer. Every time you want to change buffer you have to grab a mouse, find it and click on a little tab? Atrocious.

Bind two keys: one for "open previous buffer" and another for "open list of all buffers". And disable tabs completely, they don't bring any useful information! Only add a chore to clean them up...

CM304• 3 years ago

To commit Commit often

These are probably the most important points here, and for pretty much any other creative process you can think of. So many good things get lost because either nobody had a backup, or the only backup didn't work, or was from post whatever disaster nuked the system in the first place.

Source control fixes this problem, but only if you remember to use it properly in the first place.

Treat it like the save system in a video game; save and commit before any important changes, and after you do anything important in general.

fud101• 3 years ago

Do you branch regularly as part of this workflow?

CM304• 3 years ago

Depends on the project. New features and things do get separate branches that eventually get merged in once tested thoroughly, especially for website development projects.

But it definitely depends. A website usually benefits from feature/bugfix branches more than a game or mod does, since the latter usually has the parts so atomised that your changes to one would have basically zero effect on any others.

zubairq• 3 years ago

Yes, commit and commit often. I’d also add “write a spec before coding”

patrick451• 3 years ago

  > - No one will die
  > - Not saving lives

Tell me you write throwaway CRUD apps without telling me you write throwaway CRUD apps. If your code touches the real world, human lives are often quite literally in your hands. This idea that you can just chill out, yeat some code into prod and head to happy hour will get people killed or seriously injured.

CM304• 3 years ago

I mean, percentage wise it's likely the majority of jobs in software engineering are in fields where people won't get killed if things go wrong. Very few people die because a website goes down, a video game or desktop program has bugs in it, or most businesses lose a bit of money/have downtime.

Yes there are definitely fields where people could be killed if things go wrong, perhaps in software for cars, planes, spacecraft or medical devices. Or for dangerous fields like logging or mining, or the military.

But I suspect the ratio of people working on software that's mostly/entirely harmless compared to software that has lives on the line is probably like 80:20.

lolsal• 3 years ago

FYI this list wasn’t “everyone said every one of these things.”

Also, the “only real devs touch the real world” attitude is pretty sad. Not everyone wants to write guidance systems or heart monitoring firmware.

littlekey• 3 years ago

I’m not stupid—this just takes time

This one resonates with me. And a follow-up thought: even if I am stupid, it'll just take longer. The idea being that intelligence doesn't limit what you can do, only how fast you can do it.

Things we always remind ourselves while coding

Related Stories