Things we always remind ourselves while coding
changelog.com
changelog.com
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.
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.
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”
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.
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.
It matters nothing if anyone claims that making mistakes is human nature. What it really matters is whether your organization employs people who weaponize mistakes. Another fact of human nature is personal ambition, and there are far too many people who don't mind throwing others under the bus to use them as stepping stones in their career paths. Some of those types succeed, others try until they succeed. What's your answer for that?
The interview is not just where they figure out whether they want to hire you, but where you decide whether or not to accept their offer.
You are allowed to interview the interviewers. In fact, you'd be a fool not to, since this sends a positive signal that you are interested but not desperate. Makes you seem like a quality hire.
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.
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.
It's good advice. If you spin your wheels on things you have no control over, it's a waste of your time and energy. Focus on the things you enjoy, and the things you can change.
It’s possible to inhabit the 5% where it’s not, but it’s hard to orient towards it if you’ve never experienced it.
Congratulations. Enjoy being the exception.
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
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.
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?
The fact that there's some sample of "failed and fired" AND "failed and not fired" - even if this was 80/20, one still has to conclude that there's more than just failure at play. Inconclusive evidence to say it's only failure involved..
My experience hasn't been 80/20, it's been more 10/90. My whole company has people failing and founding around the place, I've only seen two people fired: 1 who blamed anyone else but himself, and another who never asked for help and wanted to save face at any opportunity.
Failures are a part of life, if you are at a company that doesn't acknowledge that I suggest perhaps finding someplace else for your own good
I saw an artist who did a parody of this poster that said, "Give up."
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.
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.
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.
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...
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.
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.
I learned some things. I'll consider making posters of this ;-)
> - No one will die
> - Not saving lives
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.
Also, the “only real devs touch the real world” attitude is pretty sad. Not everyone wants to write guidance systems or heart monitoring firmware.