DEV Community

Discussion on: How do you handle unproductive days at work?

Collapse
 
jwp profile image
John Peters • Edited

Excellent question... I've worked in the industry for 30 years. For "real" engineers, those who want to be game changers, love their work (maybe too much), work really hard to take it all in, been around for 10 years they too have difficulties.

Here's a few things I've learned...

1) Our physically undemanding jobs are major contributors to bad physical side effects. The best thing to do here is exercise 45 minutes a day, cut out sugar and carbs as much as you can, keep regular sleeping hours with around 8 hours per day.
2) Our industry changes so often, so rapidly and requires so much ramp up time, that we must be become believers in our learning skills, not how much we know. Look at all the changes just in the frontend.

We must stay persistent in our studies and believe that, we eventually will get there. Be a believer in yourself on learning. How many of these current trends, do you know? and how long do you think they'll take to really know?
3) Try to realize that the customer's expectations has risen exponentially; over the last 10 years to unsupportable levels. There is a shortage of developers worldwide, due to too many reasons.
4) For some reason, many developers who are good are also arrogant and lack patience. In a study 25 years ago, on leaders, (Fred Pryor Seminars) taught that only 2 in 10 people can effectively lead and or mange a group of people. They were saying a whopping 80% of our leaders are not effective.
5) Project Managers were originally trained in the old SDLC styles of project managment rejected Agile at first. People like Dean Leffingwell, the creator of SAFE deemed SDLC as "It never fit Software development, never worked, and never will". The reason: "To many spec. changes, too often, 1 year long cycles are doomed to fail"
6) Realize that Sotware problems take weeks (or even years) to solve , even when your debugging skills are excellent. One problem I'm working on now is already two years old. I study and try to find solution until I can't take it any longer and put it away for another day.
7) Software Delivery Dates almost never work. This is the reason we must adopt Continuous delivery where we deliver new features in small batches to the customer. Customers love being included in software engineering teams and should be a part of all work from the beginning.
8) Know when to reach out for help. I've found that the stress of delivering things is greatly reduced when problematic issues are brought before the team. Even when the collective whole cannot figure it out, it leads to an alternate workflow. In some cases the entire feature is nixed because nobody knew the difficulty and no customer wanted to pay for that problem.
9) I learned a long time ago, that it's always best to literally sleep on your major issues. For some reason unbeknownst to us, starting afresh the next day can very often allow us to come up with new ideas, see the issue in a different light and get that solution.
10) Realize that Software Engineering (while rewarding to our careers) is not full of Victory laps. In fact the victories that we crave are few and far between. When was the last time you had an intense feel good event, with your work? Often we are trying to "work the New York Times Crossword puzzles" and come up woefully short. The only solution for that is to vow to continue onward until you can solve the "New York Times Sunday Edition Crossword Puzzle, every day"...