How Engineers Got Exhausted
Theirs mental burnt, yet physically tired. It’s okay, there are some ways to avoid that.
This is a long article, filled with messed up thoughts in my head. So read it with some grain of salt. TLDR; scroll to bottom of the page to read the conclusion.
First, we start with the job desk of software engineer itself.
We can fairly agree that engineering and developing a software, system, or application is not an easy job to do. That’s why software engineers are paid highly. According to ChatGPT, as of September 2021, software engineer’s salary estimated around $85,000 — $150,000 p.a.
Of course, that number depends on the location, level of complexity, type of platform, and scope of work for the engineer itself. I’m not going to compare it with the salary estimation in my country, Indonesia. But I hope you get the point that,
With High Incomes, Comes High Responsibilities
You need to know that there are many steps to create an application that usable and can meet the client expectations. A fully developed design, or UI/UX design if you’re familiar, is just as a bit as 10% progress from the full project development process.
For instance, position yourself as a backend engineer who’s responsible to develop the logic and system of an application that use a microservice architecture. The scope would be:
- Provide a human-readable documentation for the APIs
- Design background process to synchronize actions, and perform asynchronous tasks
- Develop an efficient yet usable API Endpoints for frontend to consume
That’s 3 points are the bare minimum for those who perform as backend engineer. But the truth is,
There are many ways to write the API docs, and finding the correct way to write docs that can be fully read and implemented by the frontend engineer is an extra work to do.
A background process is a hole full of messed up sh*t. Concurrency, parallelism, storage, and cache management only can be done who are wise and know what they need to do. Please research more about those words if you don't really know what I meant, haha.
A “usable” APIs sometimes can't be defined as done. They, the backend engineer, need to find a way so that the frontend peoples can implement it in a more efficient manner. This is an extra work for them. Not to mention that sometime the frontend need to implement it other way and the endpoint need to be refactored.
Don’t forget that a rich-featured applications often integrated with other external services. Payment gateway, maps, localization, and other stuffs are more likely integrated with the backend rather than frontend.
Testing, testing, testing, and bug fixing, obviously.
And much other stuff. It’s so dynamic and complicated, easier to be said than done. The question is, how to fully manage that scope of work? Can we use SDLC?
How about a so-called sprint? Do you think that waterfalls are beautiful? Or maybe the god-damn great eXtreme Programming?
F*ck the SDLC, DDD is the best
Depends on the budget allocated, project time estimation, and the level of expectancy, wrong SDLC option can lead to a failed project.
SDLC (Software Development Lifecycle) is needed so that we can manage a software project process. Simply put, this is a way to communicate with engineers so that they’ll know that to do first and what to do later.
The famous Agile SDLC states that,
This type of SDLC is the favourite among startups and companies. Because it’s relatively easy to manage on smaller teams with short-range development time. But the truth that everyone didn’t know about is that, Agile is a great way to burn your money.
If you still ask why it means, you don’t really know how the Agile works. Read the article below to know more.
https://www.linkedin.com/pulse/stop-wasting-money-agile-transformations-maurizio-marcon/
In a nutcase, Agile really depends on the people’s performance. A failed task would be marked as “backlog” and a revision need to be deployed on the next sprint. Imagine there are so many backlogs that the engineer itself couldn’t handle it. The solution would be either you add more developer to the team or extend the sprint. By just blaming the developer who do the ticket doesn’t help you any further.
More people means more money to spend, a longer sprint means more money to spend. So you get the idea by now.
There is just “estimation” in Agile, not a “deadline”.
Okay, just be realistic. That’s all useless if you just want the project is fully developed as soon as possible, meet the client expectancy, and getting profit as high as the sky limit.
A faster development means more performance provided by engineer, more performance needed means more pressure need to be applied, more pressure means some “deadlines” that need to be set.
The Deadline Driven Development
DDD states that,
There’s even an article that states DDD is the most loved SDLC in my country, Indonesia. I’m not going to explain the detail about it, you can translate manually to English if you need to.
A lot of startups and companies, who still depend on “deadline” need to know that they are implementing this SDLC so far.
It’s not too bad tho, with DDD you can get faster development time by sacrificing the quality of the code or the app itself. Most of the time, your client doesn’t give a single f*ck about your code as long as the features really work as they expected.
DDD is the fastest way to make profit so far.
The Pressure They Need to Avoid
With all that fact I told you above, now you know that a pressure is good to manage engineer’s performance. But put too much of it, and you can expect a failure in the end.
Building high pressure means you’re investing in a time bomb that can explode sometime in the future.
I know that every job, low or high paying salary, have some pressure to be handled. But the point is, how you as startup or company need to avoid having a stressed engineer or developer.
Talk With Them
Communicate with your engineers, developers, or designers. Hear what they like, note what they don’t like. Negotiate with them about the contract if they feel something is not right with the current state.
Treat Them Like Human
You’re hiring a human, not a robot. You’re a naive if optimistic to expect a stable or raising performance till the end. Even big companies having lay-off to refresh their performance.
Quantity or Quality
Having limited budget and time means to have a limited option. Only a fool who wants all the goods without thinking once the bad.
Manual Test over Automated Test
When an app is still in development, It’s much wise to invest it in manual testing over time using black-box or any testing method. Automated test like Unit, Integration, and Instrumental Test only works on the happy flow of the feature. Many case and many type of the test need to be written to fully complete a single user story.
This means that writing an automated test takes a lot of time. It is recommended to write the automated test after the application is fully developed. Read more at https://www.browserstack.com/guide/learn-software-application-testing.
Help to Test Their Product
Testing an app is not just simply login, clicking, and acting like you know the feature, then blame the engineer about the error or bug you just find. You need a QA (Quality Assurance) in your team in order to maximize a chance to have a robust product. They can help you write an automated test and also ensure features are really work as expected.
If you can’t afford that, let the project manager or any lead in the project to test the product, so you can get the same level of expectancy. Because the internal tester should be someone who know how the system expected to work, or at least fully understand the user story workflow.
Choose The Right Architecture & Tech Stack
Monolith or Microservices? It depends on the scale of the team, budget, and time, not just what's you think the best for your client. For optimal results, discuss this with your engineers so that you know what they think the best, because they know what they do for the project.
If the client doesn’t request about the tech stack, decide this with the approval of the engineer so that they can give optimal performance based on their skills and experiences. A largely adopted tech-stacks are often good because there are many support exist out there on forum.
Do a Proper Way to Track Progress
Tracking development progress doesn’t mean to ask them to do some meeting 10 times a day just to confirm he is working with the sufficient workload. This is a stupid way that just makes them tired of a meeting, planning, or even communicate with you. The scary truth is, they can f*cking lie to you, if you don’t really check the real result.
Depends on your company work time and habit, tracking development ticket progress is as simple as comparing it with the latest deployed update on the app. Simply put, a working feature means that a ticket is done. This is why QA is so much helpful for the engineers. You can also track the changelog of engineer’s ticket status to decide the performance and workload result.
So what's the point of having a lot of meeting to report and discuss the progress, but still need to update the ticket status, explaining detail, and writing what the do and to-do? You think that’s the best way for developer journaling? Nope, more like the best way to waste your time.
Just plan a meet when you need to, your time is too expensive if used to talk another bs. Time is your only budget.
Stop Blaming, Start Helping
A bug or error that happened on feature means there is a failure on the development result. Who’s to blame? The one who develop that feature, of course. Blaming them, pressuring them is easy. Everyone can do that.
But what’s the point? Aren’t you a so-called development team? A single point of error in a team means that it’s the whole team fault. Do a better communication, and help your them as much as you can.
If you can code, help them to code. If you can test, help them to test. If you can remind them, help them to remind stuff. There are so much you can do than just blaming.
That’s all folks. Maybe I’ll talk about the software engineering in general at other time. See ya!
