Hacker Newsnew | past | comments | ask | show | jobs | submit | ZaoLahma's commentslogin

This is the correct way. Make it unnecessary to look at and into the clever code until it's absolutely necessary to look at and into the clever code.

The vast majority of those who are affected by what you're doing should be asking themselves why you never seem to be doing anything difficult.


It's hard to motivate high quality at high cost on subscription based platforms. We all pay the same price regardless of whether the content is barely palatable or great, and we all want new content frequently.

Better then to pump out a wide range of mediocracy to attract and keep as many subscribers as possible.


AI makes the parts of my work that I spend the least time on a whole lot quicker, but (so far / still) has negligible effects on the parts of my work that I spend the most time on.

I'm still not sure if this is due to a technological limitation or an organizational one. Most of my time is not spent on solving tech problems but rather solving "human-to-human" problems (prioritization between things that need doing, reaching consensus in large groups of people of how to do things that need doing, ...)


> That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one.

The longer I work as a software engineer, the rarer it is that I get to work with bugs that take only a day to fix.


I've found the opposite to be true, in my case.


For me the longer I work, the worse the bugs I work with become.

Nowadays, after some 17 years in the business, it's pretty much always intermittently and rarely occurring race conditions of different flavors. They might result in different behaviors (crashes, missing or wrong data, ...), but at the core of it, it's almost always race conditions.

The easy and quick to fix bugs never end up with me.


Yep. Non-determinism. Back in the day it was memory corruption caused by some race condition. By the time things have gone pop, you’re too far from the proximate cause to have useful logs or dumps.

“Happens only once every 100k runs? Won’t fix”. That works until it doesn’t, then they come looking for the poor bastard that never fixes a bug in 2 days.


My first job was as an RF (microwave) bench technician. My initial schooling was at a trade school for electronic technicians.

It was all about fixing bugs; often, terrifying ones.

That background came in handy, once I got into software.


I started life as an engineer. Try reverse engineering why an electrical device your company designed (industrial setting, so big power), occasionally and I mean, really really rarely, just explodes; burying its cover housing half way through the opposite wall.

Won’t fix doesn’t get accepted so well. Trying to work out what the hell happened from the charred remains isn’t so easy either.


Sounds like some great stories.


The worst bug in my career was when the app would reliably crash if you left it running for "long enough" - but still non-probabilistically, so sometimes it would happen in an hour, sometimes in three. The crash itself was quickly diagnosed as a corrupt vtable, but finding the piece of code that had a pointer bug in it that just happened to write into (some) object's vtable in certain situations that triggered a race condition took many days.


The reward for good work, is more work.

I tend to mostly work alone, these days (Chief Cook & Bottle-Washer).

All bugs are mine.


What kind of kitchen are you working in where bugs are a concern??!


You must work on very simple codebases


Yes and no.

I tend to work alone, so my scope is limited.

Some of the stuff I work on is quite involved, anyway.

I’ve been at this game awhile (coding for over 40 years), so I have learned a few tricks.

Of course, I “cheat.” I’ve learned to write software that doesn’t tend to have that many bugs, and I also don’t have to deal with other people’s code, so much. I write code for myself, which means that I don’t get to practice my debugging, so much, these days.

You can see for yourself. Much of my work is open-source, or source-available: https://github.com/ChrisMarshallNY


Nintendo almost managed to do the same to their own gaming machines with the absolutely insanely inadequate Nintendo Wii / Wii U decision making.

As an engineer and a consumer / customer, I simply cannot understand why there's a need to complicate things.

You have a Thing, right? It sells, right? You develop the next Thing? Great! Call it Thing 2. Instant success.


I wonder why car manufacturers don't operate like that. They might add a number to the model (e.g. "Golf IV"), but it will always be advertised as "The new VW Golf".

What would've happened if Nintendo simply would've advertised "The new Nintendo Switch"?

Never thought about that, but now it's an interesting thought experiment.


In the world of cars, industrial design is the version number. Beyond that, VW just wants to sell their latest Golf to whomever is buying a new hatchback today. End of strategy.

Numbering helps sell electronics because it makes it clear that your old phone/console is old and "needs" upgrading. It's also critical for selling software exclusive to a certain hardware generation.


They did that with the "New Nintendo 3DS". It was confusing as hell.

https://en.wikipedia.org/wiki/New_Nintendo_3DS

Things are going wrong when you have a model name like "New Nintendo 2DS XL" to describe a product IMO.

https://en.wikipedia.org/wiki/New_Nintendo_2DS_XL


I think they made like three games for that one.


Many people replace their car on a regular basis because it is considered a wear item.

With computer/console, you have to pretend the devicethey are still enjoying is obsolete to invent a need to replace it


Imagine how much more money Sony could have made if they called their latest game console Playstation Ø


Funny that you used that symbol, as it would have been a fantastically bad choice for clarity in product naming. I'm going to assume that you're German speaking and think of it as meaning "average".

In my head it would have been the "Playstation Island", while for most of the world it would probably have been the "Playstation Empty Set".


Not as fantastically bad as “Xbox One” though.


You mean the X-bone?


Playstation half-diminished, a.k.a Playstation mi7(b5)/"minor seven flat five"


Fortunately while Squarenix is still important to Playtstation (and Tetsuya Nomura to Squarenix), it's not the juggernaut it once was in the early 2000.

(for those who don't get it: Tetsuya Nomura is a director at Squarenix and known (amongst other) for its Kingdom Heart series who ends up with word salad title such as "Kingdom Hearts HD 2.8 Final Chapter Prologue" or "Kingdom Hearts 358/2 Days")


Company / professional context:

Step 1: Raise your eyes above the computer monitor in front of you. What is the team / company already using? What will they likely be using in one year from now?

Step 2: Ask yourself honestly without "I wish I could and I wish I would" - can the problem be solved using the tech that the team / company already has invested in?

Step 3: Make decisions. Default to the answer in Step 1, but consider the evaluation in Step 2. Try to get as close to 1 as possible.

At home / "for the shits and giggles": Whatever is interesting. Sometimes even bending backwards to force functionality out of tech that has absolutely no business doing what I want it to do.


my team are familiar with python, but i am not, so i decided to take an opportunity to learn this language, although, i prefer to use go because it's lightweight and simple.

at home i built my application using go. i also want to learn rust and elixir, but honestly i am not sure why i should learn both of them. i think language programming are just tools but they have their own advantages. also, learning other languages helps me become a better engineer.


As with everything, I guess do it in moderation and don't be stupid...?

Planning on being out a full day under the summer sun as a very pale north European? Slob on all the sunscreen that you can and hide in the shade when possible.

A day out in mid September / mid March when the sun is not looking to murder you? Revel in it. Soak it up. Be a plant.


Also it makes a lot of difference where you are. Scandinavians rarely wear sunscreen but their UV index is much lower than, say, California, let alone Australia.


Also, critically, get regular sun exposure so that your skin adapts. Ideally do this before it gets intense.


This won't harm Apple or its AirPod product much, if at all. The Apple brand and its eco system is strong enough for the vast majority of average EU customers to ignore the missing features and buy the products regardless (at full price).

A missing fringe feature won't drive fans of the eco system away.


Oh, if I were travelling a lot to other countries speaking to non-english speakers and an alternative offers live translation and AirPods don't. Then this is pretty much the _first_ real argument of not buying AirPods. And once you do start switching out of the ecosystem remaining in it is much less attractive


Oof...! A lot of innovation originates in engineers' "boredom".

I've been at a company that mandated innovation by having a mandatory annual innovation day, and full productivity for the rest of the year. "Be innovative for 8 hours, damn it!". That never worked. Not once. Never ever. Innovation was limited to evolution, and evolution was so slow that our customers had started implementing what we provided in house instead. Stagnation, as you call it.

I've also been at a company where people got... bored (didn't have enough to do). A guy single handedly re-wrote the firmware for a neat little hardware box that ended up saving the company an absolute ridiculous amount of money as they no longer needed to buy another much, much more expensive proprietary box.

So in my opinion having bored engineers around could very well be a sign of great success.


i can agree, but this doesnt seem like engineer boredom, more like manager or higher


> Another thought... if I'm tasked with maintaining or adding features to existing code, should I feel responsible for writing tests for the existing codebase?

Do you trust yourself enough to not break existing code while maintaining or adding features to it? What would be the consequence of you screwing up? Where would your screw up get noticed? Is it a scary person or group of people who will chase you down to fix it?

I've worked long enough to not trust myself at all anymore, regardless if it's old code or new. Then I evaluate according to above. Usually I land firmly in "yeah, better test it"-territory.


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

Search: