Thanks for the information on those situations, I didn’t know.

It was actually mostly targeted to (multiple) European countries. Yet I would probably just re-do it the same way if I re-did that, I prefer the simplicity (of the code) of having the user manually refresh the list for such niche issues over a complex code others would have to maintain. Moreover, the wifi just has to be configured once, at first install.

And you probably did not get that much time allocated to add the delay, so going with another variant could get you in trouble if it’s taking too long.

When I read that, I’m happy to not rely on tickets system / scrum or to ever get into trouble because I’m doing the right things. I would probably quit a job like that, it sounds like hell to be considered that way.

It wasn’t the most fun part of the project, and it was targeted at non-moving home devices so a more powerful wifi logic wasn’t really needed. In the rare scenario where the customer didn’t see its wifi network, he/she could just refresh the list.

I basically just added an ugly timer and moved on more important things.

I once worked on an interface for wifi network selection. The marketing people thought that the scan went too fast and that people would believe in consequence that it wasn’t powerful enough. So they asked me to add an artificial delay (multiple seconds) before showing the results.

You sound like you have an inflated opinion of your programming skills and sense of not belonging / being unlike others. I may be wrong, I don’t know you at all, but that’s what your comments makes me think - and in that case you may want to check both that ego and self-flagellation before it bites you back.

In programming jobs, there’s lot of people very good at programming but less so at social skills, it’s very frequent, I see those profiles a lot at job interviews. In that situation, you have to understand that many people are like you - and even those who don’t for the most part are not more or less able to do their job nor less smart. People thinking they’re better at programming than the rest that way are generally rightly seen as assholes, and they most often than not are detrimental to projects, as well as despised by most.

Once you get that, you have to remember to not fall into the trap of thinking that you have the higher, more important, hard skills and that this plus your poor social skills excuses you from being nice and judging questions from other as stupid or unimportant - and at interviews they’re generally prepared beforehand and have mostly deeper reasons than just the question being asked. Moreover, once you realize that many other people are actually knowing much more than you without being assholes, that might be a hard reality check.

Many people are not passionate about programming, but MANY also are, and are very competent. There’s nothing special about anyone that makes him/her immune from being outed for not being nice at interviews.

Of course those concepts are intertwined in some way.

But as a full time lead dev of a relatively big project, I find that a lot of people, often junior devs, concentrate a lot on what they think is “good code” and not a lot on whether they and other devs are having fun. It may make sense when you’re junior and you have to learn a lot at once, but when you’re experienced enough I feel that focusing on having fun, both for you and your team, should be much more important to us than focusing on precepts you read on having fast code and theoretically clean code, as long as it doesn’t lead the code to be less fun to work with in the long run.

For example, doing R&D re-implementing things from scratch, in most cases just to throw away the great majority of it, could be considered as fun by most programmers, even when it makes not much sense because what you did before also worked. As with switching some architecture around (perhaps wrongly, but it’s hard to know sometimes before you tried it).

I’ve come to very much dislike scrum or agile management as well due to all its protocols and the ways it enforces a certain way of progressing (with tickets, progress reporting, mostly short-term work) which focuses on the project’s goal (which really is what the company wants), sometimes at the expense of devs experimenting and just having fun (what I advocate we should aim for). Though it all depends on your project and company I guess.

Having fun when programming should be much more important than having correct or fast code when you’re a programmer and should be what we should aim for first.