What is the most important in daily work of software engineer? Resolving on time or with proper quality? Resolving client problem fast over good engineering? Obedience to the boss? What’s about own wellbeing?
In my opinion the basic duty of software engineering and main purpose of my job is to solve the problems of customers. Following this I’m very strict about keeping the highest possible code quality standards. Going into shortcuts often ends up painful to the team. I often meet with situation when people asked “Please approve my pull request, we will fix that later.”. No way! Such pull requests had very basic errors and were not acceptable. It is very short way to fast increase the tech debt and code illegibility (and potentialy lead to performance issues).
Moreover sometimes the expectations related to the engineering team is just “do what I said, do not think” and this is the root of evil as the boss is rarely aware about side effects of his or her decision. Also when you have too many stakeholders, they are pushing the project into various, quite often opposite, directions. Therefore when the team is put in any of such situations, it should resist by clear explanation about the real outcome of the decision. If person in charge still keeps his/her mind and is resistant to arguments, what could we do else than just do the job? It’s his/her decision and responsibility for the decision taken. However if such situation repeats often, I would change the team/job. For me, my wellbing is very important and I wouldn’t work for a long time with somebody who sabotages the project permanently.
In our daily work deadlines metter significantly. Quite often we have to sacrify something to reach the milestone as the work is underestimated. It comes from various reasons – usually it is initial bad analysis (or its lack) and changes to the scope (increase of the scope, changes to existing requirements). So how to keep the time of delivery? What can be sacrified? Usualy the victim are tests (unit tests, integration tests) and automation but rarely it is scope. I noticed real scope cutting only in well developed scrum teams working on the product. Unfortunately I never noticed that in a software house.
Always when we work, we have to balance a lot of factors together to achieve the goal of well engineered solution. It’s our personal duty as engineers to keep real engineering work over any type of pressure otherwise we will become only code writers.