Introduction
I am fortunate to have had the opportunity to challenge myself in various positions within the tech industry, ranging from roles not directly related to development to positions such as engineer, manager, and even in software development research. Occasionally, I also manage startup projects during my free time. These diverse experiences have given me a deeper insight into effective work methods, compared to those who focus solely on one field.
Honestly, I find no interest in lengthy meetings that are filled with idle chatter and discussions on trivial matters for 30 minutes. I believe other developers feel the same way. I am convinced that I could work more effectively if I did not have to participate in them.
An effective meeting should last between 30 minutes to one hour. However, creating a perfect product from a chaotic situation in just 30 minutes or an hour is challenging, if not impossible.
Top Reasons for Unhappiness Among Developers
In practice, developers require longer periods of uninterrupted time to engage and maintain focus, especially when tackling complex issues or coding new features. This is in contrast to managers, who might only need smaller hours to focus complete administrative tasks like planning, organizing meetings, and addressing managerial issues.
Below is an estimated effective time allocation for different roles within a tech organization, based on the nature and demands of their work to resolve the problem everyday effectively:
Manager: 2 hours
- Managers typically need shorter periods to complete tasks such as planning, coordinating, and managing internal and external relations. This time frame is sufficient for them to oversee daily operations without the need for prolonged focus.
Software Engineer: 4 hours
- Software engineers require longer blocks of uninterrupted time to code effectively, solve problems, and develop technical solutions. Four hours is an ideal period for them to deeply engage with their work without interruptions.
Project Manager: 2 hours
- Project managers need shorter periods to update plans, track progress, and communicate with stakeholders. Two hours is adequate for them to keep projects moving smoothly without impacting the productivity of other team members.
Researcher: 4-6 hours
- This time frame is suitable for researchers to perform tasks that require deep thinking and intense focus, especially when working on long-term research projects or complex analyses. It also allows them the flexibility needed to adapt to new findings or adjust research methods as necessary.
These estimates ensure that each team member has sufficient time to perform their duties effectively while also accommodating the unique demands and nature of each role. It is vital for organizations to maintain flexibility in adapting these time allocations based on specific project requirements and team dynamics. It’s important to note that tasks requiring shorter periods are not necessarily simpler. They often involve complex elements such as timeline, roadmap ,managing people, product oversight,,... and customer service. These components can introduce their own set of challenges, making the task equally demanding.
I love read the article from Richard Feynman:
Richard Feynman
Avoid distractions. Distractions are bad for many types of work, but especially bad for programming, because programmers tend to operate at the limit of the detail they can handle.
The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.
Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don't even start working on something hard.
We Work Differently
Each of us tackles problems in our own way, depending on our years of experience and accumulated knowledge. For example, I might take only 2 hours to solve a problem that a newcomer might spend a month struggling with. This is because I have spent years studying this issue before it actually occurred.
This demonstrates that each person and each job has its own unique characteristics, and therefore, their working time and schedule differ. I have observed that independent developers often work very efficiently because they spend most of their time solving problems.
Once, I spent 16 continuous hours solving a complex issue that no one thought could be resolved. I cannot imagine having a 16-hour meeting to resolve a problem, that would be a disaster. Problems are truly solved when we conduct regular testing and fix the errors identified during those tests. As Linus Torvalds once said about The mind behind Linux
Linux Torvalds
I am not a visionary. I’m an engineer. I do not have a five-year plan. I do not have a moonshot. I’m looking at the ground, and I want to fix the pothole that’s right in front of me before I go in.
Time to Rethink
When you are building something chaotic and complex, the process of rethinking the existing connections in your mind can take anywhere from one to two hours. Only after this period can we begin to connect these thoughts to create something new. This is why developers and software engineers often require more time. I did not fully realize this when I held positions such as Manager or Product Manager.
Imagine a typical 8-hour workday. Suppose we have a scrum meeting at 9 AM, leaving us only about 2 hours and 30 minutes to develop something in the morning. Isn't that unreasonable? For example, if we start thinking and working from 8 AM, we are interrupted by the meeting at 9 AM, and then there's no sufficient time left to start creating something in the morning because lunchtime starts at 11:30 AM. In the afternoon, we spend another 1-2 hours rethinking, and only have 2 hours left to actually write or produce something tangible in the product. If there's a two-hour meeting in the afternoon, that day surely turns into a nightmare.
Consequently, you do not have enough time to develop the project, let alone come up with breakthrough ideas.
Conclusion
We truly risk losing valuable and creative ideas if we lack flexibility in our schedules.
Most of us have different schedules and goals, so it's important to find solutions that suit the entire team to foster the development of something innovative. I am always pleased to receive constructive criticism, as it helps me learn and improve every day. Therefore, if you have any questions or feedback, I am more than happy to welcome it.
Jeff Bezos, Founder of Amazon
If you only do things where you know the answer in advance, your company goes away.