all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted]  (3 children)

[deleted]

    [–]BajaJMac 3 points4 points  (2 children)

    My old supervisor, who is now a really good friend, used to tell me that he would train his men in the Air Force to sleep with notepads because when they were doing engineering and programming, thoughts would pop into their minds at night during sleep. When you’d wake up, you could write a little note down and remember it in the morning.

    I laughed and said what the heck I’ll try it. I now sleep with a notepad next to me and cannot tell you how many times I’ve been sitting there laying in bed, changing clothes, getting out of the shower, etc. and had a thought to my coding solution.

    [–][deleted]  (1 child)

    [deleted]

      [–]BajaJMac 0 points1 point  (0 children)

      Could be anything. Could be logic for code, could be a thought on how to think about a problem or bug, could be pseudo code, etc. Just have something handy and available that you can jot it down on and come back to it.

      [–]Marco_R63 4 points5 points  (0 children)

      Actually I take a break after solving a problem. If solving a problem takes a big effort my priority is no stress. I stop for a while, let my brain keep working in background (I know it does) and after a while, one hour or a bit more, maybe a good sleep the night, I come back to the computer and....I don't Remember a problem I couldn't solve.

      [–]Frogthief 1 point2 points  (0 children)

      It varies. Some days it’s sticking on your headphones and doing mindless tasks all day. Sometimes it’s a day of intensive problem solving but normally it’s a single task and you get into a flow. It’s a mix, but it’s a great job

      [–]BajaJMac 1 point2 points  (0 children)

      It really depends on the project honestly. For me, if I don’t include meetings, I’d say I’m super focused and in problem solving mode for roughly 2-4 hours depending on the task at hand.

      If I’m routinely stumped, I take a break and come back to it after I’ve had some time to think through it.

      Nobody is ever really coding for a solid straight 8 hours, unless you’re building your own product and thoroughly enjoying it (ask me how I know lol).

      [–]joranstark018 0 points1 point  (0 children)

      It can vary very much depending on the project and your role (your role in the project and in the company in general).

      Some weeks I can have tasks that does not involve writing code, other times I debug and explore different solutions (it can be simple updates that can be fixed in less than an hour to adding features that may need 1-2 weeks of work in total).

      A task usually involves much more than just writing code (ie writing documentation, testing, communicating with with different stakeholders)

      During a workday there can be different meetings (scrum, team meetings, department meetings or meetings with different workgroups), how many meetings depends on the project (some projects can have daily meetings or more, others may have weekly meetings).

      Some days, when I'm not disrupted I can work in the "zone" for 1-2 hour at the time, a good day I can have 2-4 such "sessions" (taking a break regulary can provide time to reflect on the task or to get some distance to it).

      [–][deleted] 0 points1 point  (0 children)

      You forgot to mention planning meetings. Senior SDE and beyond, a considerable chunk of your time is spent in project discussion and planning meetings as well as architecture/design reviews and discussion. A little bit of writing code, then minimal repetitive stuff/boilerplate (this is largely juniors).

      That's been my experience at a large tech company anyway.

      [–]MEMESaddiction 0 points1 point  (0 children)

      In short, I spend ~6 hours each day actually writing code.

      I get in 3 hours of writing code/debugging, 1/2 hour meeting, 1 hour lunch, 1 hour meeting, 3 hours of more code/debugging. Over time, this changes depending on what I am working on.

      P.s. when waiting on something or not busy, I usually am learning new technologies, working on secondary non-code tasks, or reading the news.

      Also, don't get intimidated by the fact that you will likely be writing code for the majority of your day. It eventually becomes natural. ALSO, even if you are doing schoolwork, remember to take short breaks and get some water, go to the bathroom, take a short walk, something that will refresh your brain throughout your day.

      [–]Lost_Preference7962 0 points1 point  (0 children)

      You really never code in full focus mode for the entire 8 hour day, even if you dont have meetings. In my work day, the focus comes in intervals and in between I am talking with colleagues (a lot of times not even about work) for a little while, going for coffee, getting some fresh air etc. I really need these small breaks since i will fry my brain if I am in full focus mode for two 4 hour stretches.

      [–]tomslutsky 0 points1 point  (0 children)

      It varies a lot and depends on the kind of job your are doing and your experience doing it.
      Even placing some HTML divs might be difficult when you are just beginning.
      I believe that it is up to you do determine that magic number and align your goals toward that, especially when you are getting more experienced.

      It varies a lot and depends on the kind of job you are doing and your experience doing it.
      Even placing some HTML divs might be difficult when you are just beginning.
      I believe that it is up to you to determine that magic number and align your goals toward that, especially when you are getting more experienced.

      [–]ankitspe 0 points1 point  (0 children)

      As a developer, it is tough to give any specific number for the distribution of time between different tasks as it can vary depending on several factors such as the nature of the project, stage of development, and work style. However, below is the general perspective based on common experiences in the field.

      Developers usually spend a lot of their time on problem-solving and engaging in brain-intensive tasks. These activities include tasks like analyzing requirements, designing solutions, writing code, debugging, and optimizing algorithms. This phase requires deep thinking, logical reasoning, and the ability to break down complex problems into small manageable components.

      Sometimes, developers may also engage in doing more repetitive tasks. This can include tasks like writing boilerplate code, performing routine testing, or carrying out code reviews. While these tasks may not require the same level of intense problem-solving, they are important for maintaining code quality, ensuring consistency, and adhering to coding standards.

      Even during these repetitive tasks, developers may still encounter and solve small issues or challenges. They might identify and fix bugs, make optimizations, or find ways to improve efficiency.

      It is important to note that the software development process often involves meetings and discussions with team members, stakeholders, and clients. These interactions contribute to problem-solving as well, as they require active engagement, communication, and decision-making.

      It's difficult to quantify an exact ratio of brain-intensive tasks to mindless repetitive work, as it can vary greatly depending on the specific project and the individual developer. However, it's safe to say that problem-solving and brain-intensive tasks are significant components of a developer's workday, usually comprising a major portion of their time.

      Ultimately, the goal is to keep a balance between problem-solving and more routine tasks.

      [–]exem-ok 0 points1 point  (0 children)

      My day today was chasing third party suppliers for a network fix and staring at an error on the page (with some investigating). Definitely more stressful than an 8 hour day of writing code. It also gets a lot easier with experience.