Jose J. Fernández

This also happens in the Midsize Companies I have worked for, and also in the Small Companies where management was not technical or had no interest in technical topics.

I think key factors are:

• Distance with managers. More is worse.
• Interest/knowledge they have in technical endeavors. Less is worse.
• Layers of management. More is worse.

That said, and whereas the advice might be effective, it also sucks to not be true to your own values. I would suggest to try to be communicative, but maybe don’t become the asshole we all hate. And try to know more about the company on this regard while interviewing. Difficult, true, but include this in the list of factors when deciding which companies to join.

I from time to time do something like what you are looking for, I believe. But I also think that it’s going to be difficult to find those “solid specifications you might get from a customer”.

What I do is to start a project that usually reinvents the wheel, so you know exactly what is needed, and focus on experimenting at different levels as you said: architecture, project management, design, UI, coding, CI/CD, pipelines, quality, etc. You also end up learning a lot about the problem itself.

For me the goal of those projects has not traditionally be to release something and create the next startup, but to experiment and have some fun. In my last project I also tried OpenFastTrack, which is a tool for gathering requirements and tracking their completion in the repository.

It was a lot of fun. Maybe this sounds good to you, and the truth is I have been looking forward to collaborate with others with the same approach, to also introduce the “autonomous team” factor to the experimentation 🙂.

I think if you can achieve what you want with HTML, CSS and JavaScript by yourself, any static site generator will allow you to do it. They just automate filling in HTML templates, which you can create yourself too.

I know Hugo. It’s simple and, as I mentioned, I do by myself what I don’t find out there.

I think what you are saying is technically correct, but it fails to acknowledge the importance of human emotions. Emotions are involved in everything humans do, and since software is written by humans for now, the act of developing software also involves emotions.

This does not mean that it should be a emotion-driven discipline or that emotional arguments should be weighted more than other kind of arguments. It just means that everyone will deal with human emotions while developing software, both their own and others’. We can of course manage our own emotions as we wish, but then the question is how do we act on regard of others’.

My main thought here is that disregarding how others feel about your actions rarely helps anyone. When collaborating with others, we usually aim for getting the most out of that collaboration. That is only achievable if the other person feels safe and welcome. Maybe writing some harsh comments in a code review is not the best way to do that.

Next thing that needs consideration is that we are all different, and what for one is a small gesture, for other might be offensive. You don’t know everyone else’s personal history, background or experiences, so you don’t know what can negatively affect them. This needs to be acknowledged, particularly when working in heterogeneous groups (ie, people from other cultures). You can ignore this fact, but it will negatively affect the collaboration.

As with everything else, people can become better at communication and collaborating with others, and still be able to defend your points without being aggresive.

Why don’t they, then? My first guess would be that this is seen as irrelevant. This is how I do things, how we do things in this industry, learn to deal with it. I don’t think that is a good approach. It does not harm your engineering skills nor the product of your work to be kind to others. On the opposite, it makes their lifes easier. I don’t see a reason why we shouldn’t strive to do that.