i'm working at my first big company. even within the company it seems that our engineers have vastly different types of jobs. some spend a lot of time writing application code. many others doing devops and configuration/deployment (and just justifying the work they're doing or waiting for answers).
When I was senior at a 500 person company, I could spend half the day or less in meetings, but not every day. Maybe 70% coding.
When I was at more of a start up and midlevel, my meetings tended to be 1hr-2hr or less a day, several days only with scrum.
When not coding/testing/code-reviewing, it is meetings, notes, documents, communications, driving alignment, finding requirements, digging into data, ...
Typing code is the easiest part!
The tough part is the whole thought process you have to go through to visually see the whole picture more or less completed.
First, write it down, break it to smaller pieces, find potential obstacles that could backfire at any time, break it down to even smaller pieces if possible, and then convert the whole procedure to coding.
To me the most difficult, yet challenging thing to achieve is to train your mind to think as simple as possible, to the point of exhaustion.
If you start thinking complicated patterns and methodologies, eventually you will end up with an over-engineered infrastructure that could have originally been implemented with standard tech stack, for example in web development with LAMP and a shared hosting service.
If code base is rather small, refactor as soon as possible and follow techniques that allow you to expand your project(s); else, you end up maintaining legacy code that takes a great amount of effort to interpret of what actually does...and good luck with that!
On a day-to-day basis, there's always going to be a cyclical element -- I just spent two weeks writing code nine hours a day to push through a big feature, and now I expect to spend a week or two on less focused work, catching up on all the things I ignored while I was heads down.
I also try to turn non-code work into coding work. In lieu of doing a BUFD, I'll try to throw together a proof-of-concept or do a spike. Whenever there's a production issue, I try to turn that into a project to eliminate that class of issue. If there's some repetitive administration to do, I try to automate it.
I disagree. While the skilled developer might add to the teams output, a skilled manager will multiply the output (by 1.x) of the whole team.
If I start spending a lot of my time coding, that means I'm running off without getting requirements, or I'm stuck with a problem I don't know how to make progress on. So for me this is a good cadence.
- Reading code: 20% - Writing code: 10% - Debugging code: 20% - Meetings / administrata: 10% - Other productive tasks: 10% - Goofing off: 30%
-Reading Code: 3% -Writing Code: 2% -Debugging: 15% -Meetings/Administrata: 20% -Docmentation/Paperwork: 20% -Testing: 20% -Other productive tasks: 15% -Goofing off: 5%
Note: When I say "debugging", it's often not debugging code. Sometimes it is, other times it's user-error, hardware malfunction, mis-understanding of the spec, etc.. A good chunk of debugging time is spent eliminating software as the failure. I work on highly regulated medical devices and their connected systems.
So there are weeks with 30% coding and others with 50% but not much above that.
I am curious as to what you mean by this? It sounds like you are suggesting that this work is not valid? Is that what you think?
"He had heard in college that in industry, a hundred lines of finished code a week is considered good performance."