I hope I can explain my question correctly.
How do professionals work when they program something from scratch or work on a hard problem?
When I (re)write a program from the scratch, or work on a serious problem, sometimes a break helps me a lot.
It sounds strange, I try very hard, but when I do something else (walk, sleep from 11.30 pm to 5.30 am, go shopping, or have a coffee with my wife), I suddenly have an idea, or just a new approach.
But I only program privately.
What do you do in a company when you have to program 8 hours (or even more)?
You can't say: I have to have a relaxed coffee with my wife.
Don't get me wrong, that's not laziness. I absolutely want to solve it. But... sometimes absolute concentration on a problem doesn't help anymore. Before the break I sat on the problem for at least 2 to 3 hours.
How do you do it, if you are paid for coding in a company?
Have you ever heard of Ballmer Peak?
In short, it is claimed that if you had a shot or two, you'd perform surprisingly better at programming, and finding solutions to problems in general. Is it real? To some extent. Innovative ideas often comes from people who were not working in that particular field, it comes from building connections between aspects and existing ideas which were not previously connected. When you were shopping or having coffee with your wife, it is possible that your subconscious mind was making these connections. A similar effect is said to present itself when you hit the Ballmer Peak (don't quote me on this one though).
Likewise, when you are working for a company, it is highly unlikely that you will be sitting in front of your computer for 8 hours straight. What I do is I walk around the corridor, a lot. We have tons of snacks around the cubicles and we spent as much time eating them as we code. The thing is, you don't have to program around the clock.
Another thing that you can do if you've hit depression on a project or task, would be to present your project and its current status, to your team / colleagues. It really depends on your team, your supervisor and the norm of the workplace, and you might think that it is ridiculous to add even more pressure onto yourself with a presentation when you are already stuck with a problem you can't solve, but if you are willing to open up and be honest about it, it would be the case wherein your colleagues can give you brilliant ideas to overcome the problem(s) that you are facing.
There are quite an amount of non-coding tasks which you can take up when you feel like you've hit a wall. As unlikely as it sounds, one of those that really clears my mind would be documentation, perhaps the dullest part of building something.
In the process of documenting what you've done, you are given the chance to reflect on those actions, and a huge part of that process IMO, comes down to us wondering why we didn't do things differently when it clearly could have been better / written in a more efficient, cleaner way. There are pieces of code which I've made major changes to at least tens of times thanks to flaws and new ideas that I've discovered in the middle of completing its documentation.
Most people here already touched on several points so I'll just share my experience.
In both research and working in the field, it's important to organize your thoughts before writing any code. My colleagues and I will take time to formulate a plan of action for all projects before just jumping into coding. (Solve the problem, then write the code)
However, things do not always go the way you expect them to. Sometimes the logic is wrong and we have to take the time to go over what we've done and correct it (Remember the infamous quote about the definition of insanity). Or maybe someone isn't pulling their weight. Or maybe someone forgot to submit changes to their portion of code (😡). The list is endless for things that could go wrong.
Then there's the proverbial wall everyone hits: the time where you don't know how to proceed next. With this, I learned to not overthink about things and take breaks. Breaks relieve stress and allow your brain a chance to rest. Lastly, never be afraid to ask for help!
If you reach flow/the programmer tunnel/whatever you call it you can go for 8-12 hours, even though it is draining. It never happens though because of shared offices where everyone keeps talking to you and diverts your attention. Also meetings.
I'd say in a work environment I can't do more than 5 hours of serious work per day and the logical conclusion is that you spend the rest of the day trying to look busy and doing minor tasks that could be completed in 1/4th the time. (I'm not alone with this either.)
[Part 2 of 3]
Sven_m I've been where you are... so close... you just need to keep at it for a little longer and don't want to stop for fear of losing all that context you have in your head to solve the problem.
I get it. But trust me... walk away and rebuild that context from scratch with a fresh perspective. It will help reveal something you were too close to notice before.
I only figured this out after spinning my wheels many times over before trying this approach.
The strange thing is... it's been many, many years since I've experienced something like that where I would just be stumped. I've developed a sort of mental muscle memory where I can anticipate the possible issues with any number of approaches almost without much effort.
When I'm pair programming with my team, I coach them on trying to isolate the issue by anticipating beyond the code immediately in front of them.
I'll need to expand on this concept in a follow up article or something when I have time.
[Part 1 of 3]
Hatsy Rei Ballmer Peak! 😂🤣
It sounds like my steady intake of caffeine. Time to change out my I.V. drip. 🤣
I completely agree about walking away from the problem and returning to it at some point, whether it's 30 minutes later or the next day. If you're too close to the trees to see the forest, you have to take a step back and see all the pieces for proper context.
Schindlabua, if I managed 5 hours of coding without meetings, lunch breaks, office distractions, it would pale in comparison to reaching the "zone" I've described in other posts. This is what you were referring to in your post. We all call it something different. I think Morpheus calls it "Beast Mode" 🤣.
Once I'm in that "zone," I lose track of time, don't notice people talking to me, and I can keep a deep, sustained focus and steady momentum of highly productive coding for many hours on end before I find myself crashing to sleep.
It's so satisfying when I can crank out so much in a short period l like a hackathon... 🤓
[Part 3 of 3]
It's the same approach I use for learning new languages, writing new code / refining existing code, learning new frameworks, reverse engineering a system / platform /application, etc.
Anticipating the next few steps becomes natural at some point, it's like preloading the next blocks of code while you're still coding the current blocks.
Anyway, for me, these days, I rarely get stuck. While this isn't the same for those less experienced on my team, we help coach them when they're stuck. Rather than just revealing the issue, we guide them along the way on how we're discovering the issue so they can gain the techniques themselves.
I hope this was helpful insight. 👌
Thank you for your long answer Mr Schindabua Sir and Mr Carroll Sir.
I didn't know the...? condition is known.
Flow, beastmode, tunnel.
It's really a kind of condition. It's pulling.
I wrote a program and my friends want to use it. That motivates me.
This is the first time that one of my programs is really useful (for my friends) and they want it.
I thank you for the answers, I have been reading the whole time.
Its a great feeling to build something useful.
I will continue now :)
Sven_m I don't know if flow, beast mode, tunnel are official technical terms. At least the Ballmer Peak seems to have a reference outside of Sololearn albeit a comical one. Something tells me that it was designed to make fun of Steve Ballmer of Microsoft 😂. Anyway I've heard that large companies like Google provide programmers with ample recreational freedom to help them step back from a dead end situation and reapproach the problem from a different angle and a new mindset. Not all workplaces may have the funds to provide the luxuries to its employees that Google does. In fact, on the other end of the scale are those workplaces that treat their employees like wage slaves with almost military like discipline. However, the latter would not work very well with creative disciplines such as the building of software.
Thank you for your long answer sir.
No, I will not quote you :)
Ah, a bite to eat or a coffee at the window is okay. That helps a lot.
Thank you for the other tips too.
I don't know what I expected, but the idea of not being able to pause, because you program for a company was frightening.
It's more that I have a hard time getting away from the task.
I always think: I'll have it soon. Or: That must work!
It even becomes difficult for me to do something else. I'm a little unfocused because I'm always thinking about the task.
But I have noticed, strangely, it helps a lot.
Sven_m you ve just described the cancer of most companies. Only few companies have understood that problem solver (programmer) must be independent and free and these companies are the most successful. They let programmers do what they like while the work, like playing ping-pong, eating snacks, drinking coffee, chatting, or whatever the prefer. Some of them prefer to sleep inside their workplaces or even near their computer. On the other hand, there are companies which force programmers to work under deadly deadlines and for 8-10 hours with only a 30 minutes brake. In the end these companies have programmers with health problems and this leads to unsuccessful results.
The choice is (y)ours.
Thank you for your answer Sonic Sir.
For creative work, I imagine it cruel. You just can't get any further and have to drink the coffee in your fantasy and stare further at the screen.
My initial question was how to do it in companies.
I can stop/pause at any time.
I once talked to a programmer from the industry. He programs robot arms. Microcontroller/ C#.
He said he changes 95% of the existing code. Only 5% he really writes completely new programs.
He was rarely in a dead end because it is nothing new.
I think he was a bit annoyed anyway, with all my questions :D
Very complicated vs huge programs need very huge meditation! Like chess.
You have to say this to you'r boss, and drink you'r coffee again.
I hope you be in a huge company with a huge boss.🙂
(Don't create big airplain in the little garage.)
This is a great thread, it's interesting reading everyone's experiences. This balance is definitely worth bearing in mind when looking for a new job, particularly how they implement it in their workplace.
At my job I can take breaks whenever I like, I can wear headphones all day and work flexible hours. So many times I've walked away from my desk with a headache, taken a long lunch, then immediately spotted the problem on my return.
Breaks are important for such a thought-intensive role and your prospective workplace should encourage them.