I'd love to know, from developers who are being paid to write code, what it is that's stopping you from coding (apart from the obvious, that you're busy browsing HN!).
I am getting paid to get things done in a good manner. If I wanted to have a house built for me, I would not expect to pay somebody and immediately have them start laying bricks without them looking at the land, taking soil samples, sketching up drafts of what the house should look like within the constraints available, and then plan the foundation of which to start building.
If they came and immediately just started laying bricks, I'd know I have a really shitty house builder.
I mean no offense by this, but "why aren't you X" is a bit naïve and comes off as lacking a good amount of experience in that field. There are many reasons why not doing X is right, including social/mental recovery and prevention of burnout.
The UI requirements to my ticket didn't make sense. The changes the other dev wanted would have took us possible days. I was hesitant to start, so I asked another dev... He said something totally different, he kept referring to something the designer wanted, but it didn't make sense to me, either. I called the designer and she told me she never said that and we agreed on something else. After confirming with another dev in chat that the designer was right, I could start coding.
In the end, after 20 minutes of calls/chat and around 30 minutes coding, the issue was resolved. I saved so much time (days, really) just by being a bit sceptical.
I'm new on the team, so first I thought it is just me who can't follow everything, then asked around and realized that the level of miscommunication is shocking and people don't even realize that they don't understand things and act like everything is trivially simple (the team looks good, though).
Often, unclear description or Acceptance Criteria means that the ticket hasn't been though out properly and needs to be clarified (or scrapped).
I've just recently encountered a ticket from a certain person that does this all the time. The problem is that their criteria still only describe the solutions they imagined themselves, which are often… very suboptimal.
In the end, what you want is someone who is capable and willing to properly root cause a problem and weigh multiple possible solutions against each other. If nobody does this, no amount of superficial process will help you.
I had the misfortune of assuming people want to communicate more in order to avoid miscommunication but it turned out that the team (~5 developers in a ~15 person company) actually wanted more walls around them, minimize communication and focus on silo'd development (one frontend, one backend, one ios, one android and one infrastructure with 0 sharing of tasks even if one was behind/in front) with as little communication between devs and others in the company as possible. Only the person dedicated for communication should do the communication.
I didn't agree with this so I no longer work there, but there was a few months of pain because I assumed everyone wanted to communicate but didn't have the experience/tools/processes to do so. I was wrong, which took time to discover as I assumed everyone wanted agile collaboration.
In the classic methodologies, you had some document, that told you what to do. In agile you should talk about things and just use a few notes to summarize what should be done.
Acceptance criteria are a (good) tool to drive the discussion into a specific, rather than abstract, direction, but should not replace verbal communication.
What if asking questions significantly increases quality and productivity? I mean, strictly speaking, Agile is no methodology but more a set of values [1], that defines a culture rather than a methodology. Yes, there are agile methodologies (Scrum, XP, etc.), but those are worthless without the right culture.
In fact, I think you are better off with the waterfall methods, if your company has no ambitions of changing the culture. So the correct combination of culture and methodology is critical.
Culture either allows and values questions and improvememt or it doesn't. If it doesn't then methodology will not override (read: fix) that.
Waterfall or not, or otherwise isn't really relevant. Culture is.
Then what is it?
In particular, architectural discussions benefit pretty little from prototyping in the initial phases. If you want to decide if your next system should be microservice based or monolithic, prototyping won't do much.
Similarly, if the basic requirements are not yet understood, asking questions about them is more efficient than implementing a version of possible requirements and asking others to correct it.
How can this be? Did you never learn how to use source control? Coding is the best way to explore the solution space, doesn't mean you use whatever you write right now.
My current guidelines for myself are
1. Take a few minutes (or hours, depending on problem size) to write a clear plan for a proof of concept. What's the terrible, crappy, bare minimum that shows your goal is feasible?
2. Run that document past another person. See if they can simplify the plan for you or find things you overlooked.
3. Hack out the POC.
4. Run the POC past a real person. See if they catch issues in your approach that would be blockers in a production version and resolve them if possible.
5. Write the spec for the actual feature/program based on what you learned from the POC. It doesn't need to be super-detailed or perfect; it just needs to capture the lessons you've learned and give a clear direction for building the real thing.
6. Run the spec past another person. Incorporate their feedback.
7. Write the production version.
This works out pretty well if you keep your specs as plain text in the project repo. You can do the whole process with a standard code review flow.
A no code solution to a problem tends to be better than one with code
But if you're still at the big picture level, code is a horrible way to express that. It inevitably takes you into the weeds.
Reasoning:
If you're coding, that counts as working. But if you're working, that doesn't mean that you are coding.
Obviously yours works too though (You have to do some programming, but you also have to do other things).
In the software world most of those would be accomplished by coding though. You code up prototypes, show them to people, ask questions, test performance, test the different dependencies etc. Making a big design up front as you suggest instead of just coding prototypes is naive and wastes time. It is a good way to look productive to management though, I give you that.
It rarely happens that once a prototype is written, the developer finds out it was all a wastage and the customer wanted something quite different.
Think of the prototype as a Photoshop mock, but interactive like the real application.
If you’ve never had to write down and get feedback on a system design that is entirely okay, but as you work on projects of increasing complexity and scope, it becomes more and more important to plan before you write.
The prototypes you’re describing are primarily useful for UX iteration, not system design.
Think of it as the scale model of the house in the original example. It’s a way for sake holder to see and feel what they’re going to get.
Abridged and abstracted documents add their own confusion.
I'll counter that with a real-world experience.
I contracted at a well known company that did system design & documentation first, without doing prototyping, etc. My first day working on the UI I pointed out that the web app had so many menus that the actual content would barely fit on a 15" laptop screens.
The team debated and debated on how to fix it, but ultimately it kept getting trumped by the documentation team who said the docs are done so we couldn't change anything. I left after a couple of months. They worked on it for a year before finally tossing it out.
I'll counter that with a real-world experience.
I worked at a well known company that did system design & documentation first, without doing prototyping, etc. My first day working on the UI I pointed out that the web app had so many menus that the actual content would barely fit on a 15" laptop screen.
The team debated and debated on how to fix it, but ultimately it kept getting trumped by the documentation team who said the docs are done so we couldn't change anything.
I left after a couple of months. They worked on it for a year before finally tossing it out.
In my experience this leads to mediocre results. You need to throw out prototypes often, otherwise you'll end up with shitty solutions.
It's an unfortunate fact that as soon as you see a prototype, everyones instict is to fix the most glaring issues and call it done.
But to get to a truly great solution, you often have to throw out the prototype, and start all over.
Unfortunately very few people have the patience for that. Usually the prototype already took so much time, that everyone is already totally stressed, and starting over is out of the question.
If throwing the prototype away isn't possible, it's not really a prototype anymore.
Implementation is work. It's a phase in the SDLC.
> Coding is not Accomplishing Goals.
If the goal of a particular task is defined as a code deliverable, then coding will help you accomplish that goal.
You suggested the question seems naive, but you’ve also listed plenty of good answers to “why aren’t you coding?”
I’m not sure you can attribute naivety to a simple question like this, and I don’t think it’s necessary. It’s just a question. It’s prompted some interesting responses in this thread.
And I’m fascinated by some of the responses to this question, including the post I was responding to. It’s really interesting.
I come with my own bias, I’d like to code more, and arguably need to, but don’t always manage the non-coding side of my work in the most optimal way.
Really interesting to read everyone’s thoughts.
Coding is a means, not an ends.
Working hard is easy. Working smart is hard.
Working hard can become very cumbersome and/or annoying to deal with from a team perspective if you don't align with your team/customers/stakeholders/etc.
The worst thing that happened to coding is business culture with design docs, architecture docs, whatever docs all coming before a prototype is written. This is how you end up with "enterprise grade" garbage.
The best way to create a good code base is to write it inside out a few times over. Documents ain't gonna help you.
For the same reason our job's don't stop when we go home (or turn off slack) either, we are essentially paid to think and our brains do not care about the arbitrary thresholds set by 9-5. I fully realise how much someone is actually able to practice this has more to do with the organisation they work for appreciating the difference between cognitive and manual work.
Yes, I agree but also feel it's a natural risk for any cognitive work. But not every day feels very effective forcing work hours for me, it's a hard balance, one I usually ensure stays in check with some outdoor activities that are currently not allowed :/
A lot of the problem set is debugging people and teams. For example “why is x person performing differently” and the debugger are time boxed to 1:1s, sprint cadence meetings, and looking at output, so the thinking between those debugging events is increased because you can’t just brute force it like a sticky code problem.
I think the pandemic has worsened this. Pre-pandemic I had a 40 min walk buffer to and from work where I’d naturally start thinking about my own life. Others had dedicated offices at home and other social interactions, or a coworking space.
Now most social interactions and validation for many come from work slack or zoom, no commute for everyone, and for those in smaller spaces their living room or kitchen or bedroom is their office so work is always within reach and their is no buffer. There’s also not much else to do.
So even if you can pull yourself away from your laptop your thoughts are more often than not focused on solving these kinds of work problems.
The vast majority of my job, outside of writing efficient and secure code, is learning about other systems and domains. Software Engineers can be employed in anything from financial technology to healthcare to kids toys. You're going to have to step outside of your depth a lot and at least having some shallow platform to stand on is imperative.
Often it's showing people another way to use an existing feature
Speak for yourself. Some of us have been there, burnt out and had to rebuild our relationship with work in a healthy manner. I think no matter what you do, if it is thought work and you don't find a wat to turn it off, you are doing yourself a diservice.
I loved what I did for 10 years, then all of a sudden I didn't. It was like my brain had cottoned on to the fact that software was where all my stress came from and I felt ill even thinking about sitting at a computer. I have rebuilt my relationship with software into a more healthy one since then, but it bares mentioning time again. The software industry will burn your wick at both ends and then toss you asside when you're no longer young and stupid enough to work more than a normal work week.
Sorry to be so cynical, just be careful is all.
THIS.
I think they may be referring to the phenomenon of walking away and having the solution "come to you" while doing something else. It took me a while to appreciate this, but simply walking away is often the fastest way for me to solve a hard problem. There I am, lying in bed, or cooking, or whatever, and BOOM the solution is presented to me - just like the divine inspiration described by so many. Of course, now we (hopefully) know that it's probably less a matter of intervention and more a matter of brain chemistry, but true regardless.
“Is this pleasant?” “Is this unpleasant?” “Is this neutral”
For example, I walk into a room thinking about work, sit down still thinking about work, and finally notice I’m thinking about work, so I ask myself the questions. Is the chair alright? How do I feel? Hungry? Cold or tired? No, this chair and room are comfortable. I’m safe, my family are nearby, I just ate a nice sandwich etc... that’s pretty good.
It forces me back into the present. Added bonus, the moment you label anything as neutral it transforms into pleasant, because anything not unpleasant is pleasant!
You could try it continuously or set alarms or just ask yourself often. Whatever suits you.
I used to believe and practice that, but that's what led to a lot of life dissatisfaction and burnout and near-burnout.
Sure, not saying I never think about my work outside work hours, but these days I start work in the morning, stop in the evening, and in general don't worry about it until the next morning. That tends to make the hours I am working much more productive, and avoids huge variance in productivity as I swing toward and away from burnout periodically.
And I say this as someone who loves programming, and did it as a hobby before I did it professionally. For a good 8 years I didn't want to touch a code editor outside of my job; I just had no creativity and desire left for my own projects after being always-on work-wise for so long. Now that I've enforced more separation between my professional and personal lives, I'm able to do it as a hobby again sometimes without being burned out on it after work is done.
Had a coworker get promoted way past his level of incompetence. He never accomplished much before, but afterward he spent all of his time lobbying for his ideas and undermining those of us that were trying to get work done. Wasted a lot of time dealing with him until mgmt got a rare clue.
Another coworker would ask a 5 minute question and an hour later come back and spend a 1/2 hour telling me over and over how my answer helped him solve his problem.
Incomprehensible emails from corporate telling us something that might or might not be important. We had to try to decipher them to be sure. Much unproductive discussion ensues.
Had an company exec that liked to go around glad handing everyone. Nice guy, but man could he blow a couple hours of our time.
Woman in the next cubicle arguing with her kids over the phone - loudly - for two hours.
A loud snuffler in another cubicle. Still can't understand how he didn't give himself brain damage.
Yak shaving: get a bug report. Run the debugger: crashes with no message. Research debugger failure to no avail. Go to file a problem report: reporting tool is down.
I'm sure a lot of people have this problem: naming things. Can't code until you figure out what that variable should be called.
i, j, k, foo, bar, baz, and don't waste a moment thinking about it till your solution is finished and warrants a once-over (or till it has grown sufficiently complicated that a real name is finally necessary even if temporary -- try to work in small enough units that this never happens).
I, j, and k have clear definitions as basis vectors, so they can be used, but I don't think I'd ever call a variable foo or bar
https://geekhack.org/index.php?topic=95872.0
I do think we need a modern hacking keyboard though.
I can understand that viewpoint. On the other hand, you have to develop that understanding somewhere, and on some problems I find that sketching out a solution in code is more productive than using a whiteboard or some other mechanism, especially if I already have a rough idea of what needs to happen.
E.g., I might know that I need to keep around a little intermediate state, and I'll throw that in an unremarkably named variable and iteratively build up the rest of the algorithm. Once I have _some_ solution I can go back and see if the variable was really important, prove it correct (or find additional work to do), and dole out meaningful names.
The idea isn't that different from how when building up something which needs a loop you might start with "while (True) {}", figure out where you need to break, and then go back and factor in an appropriate stopping condition once you understand exactly what the loop needs to do to accomplish your goals.
Whereas my programming and design work has only reached tens of thousands interacting with it over the last two years this is hopefully seeding for a big future.
The enabler 10x engineer may be true - even though I've never found managers so good to multiply their team output dramatically while I've met 10x engineers building incredibly fast and slaving away for a chance to make millions. It could be that's because I found enablers in large companies, where no-one is motivated enough to make millions for rich shareholders somewhere.
This is why I’ve retired and am just doing my own projects
Literally every project they were involved in would get slower as people needed to stop everything to deal with them.
This isn't Mythical Man Month stuff either - no matter the size of the new project, adding specific engineers to the project made progress not just halt, but actually go backwards, as all the stuff that worked before was now broken.
EDIT: And yes, bad management was a major issue with the team but some engineers seem to be negative sum, even taking management into account.
The on call person, for the week, doesn’t have sprint commitments. If they have time, they can choose to help the sprint or work to reduce toil.
The habit of check the docs first and maintaining docs in this way is really critical for remote teams and bandwidth.
People tend to have similar questions, and other team members have answers I don't, so having everyone in a room together is handy
Feature request: when someone goes to "https://whyarentyoucoding.com/", can you cleanly redirect them to "whyarentyoucoding.com/NAMEOFCURRENTCOMIC"? It makes it easier to share the latest comic since sharing whyarentyoucoding.com results in a stale link after a few days.
I've been on sick leave for over half a year now. Luckily I am in a country where I am protected, but I'm receiving less salary as the law indicates. I'm trying to focus on the good things in life. In my downtime from work I've tried to start a few personal projects, but I just can't seem to stick with it and I end up just playing video games all day. I just wanna crawl into the fetal position and die sometimes. I've often contemplated suicide but I know it's not the way out and it'll hurt the people who love me more than it will help me. I haven't told anyone the last part yet, including my therapist. I know I'll never make that move, but it has been on my mind.
I'm working 2 half days a week now, and it's hard. Therapy helps, even if it's just someone I can talk to without judgement, but I'm afraid I'm going to have to stop soon because it's costing me too much. Unfortunately the waiting list for therapy covered by insurance is extremely long.
Covid was part of the problem. Because of it, we just got more work and longer hours and I was given some high stress projects and clients that were way beyond my capacity. Couple that with WFH and a bunch of other personal things that happened, I got a burn out. Without going into details, I feel my employer failed to protect me and our relationship has soured. I want to quit and find a new job, but because of my situation I can't just start a new job and work 40 hours again. OTOH continuing where I work now is just causing me more and more stress and anxiety I'm also underpaid for my level, and on top of that I'm only earning 70% because of my sick leave. Rock and a hard place and all that.
I'm lucky to have my partner, she tries to be understanding but she's also had a tough year.
Anyway, that's why I'm not coding.
1. I am stuck in a meeting
2. Everyone is arguing about requirements in Slack and I am waiting for that to sort itself out.
3. I am coding, just a Reddit script instead of my work.
4. A fellow developer friend is also not coding and wanted to chat.
5. My Surface blue screened.
6. I have to write a pull request
7. The API I am working with is down
8. With work from home, my thoughts drift to napping
9. I am on Udemy figuring how to code it
-> my afternoon today
- Depressed
- Anxious
- Covid-induced (likely) brain fog (maybe the depression/anxiety also is from presumably having covid back in April)
- Can't find a freelance client
- Broke
- Want a passion project
- Want to be part of a co-op not a cog in a machine
- Want to be on a team again
- Can't pick a side project to work on for some cashflow
- Too busy promoting my gofundme to pay rent
- Want to be a game dev this week
- Will want to be a systems dev next week
- Wanted to be a blockchain dev last week
- ADHD (apparent?)
- Mid-life crisis? Or is it just covid brain
- Wow, this has been catharctic just free-writing like this.
- Are you still reading this?
- Really bad schedule
- Brain struggling with organization
- MOTIVATION <--- mostly that..or the lack thereof.
- I'm 41, I guess as senior a dev as you can be in php/vue, feel like a junior dev, imposter syndrome.
Of course then there are days when I just don't feel like it. I get paid hourly so I don't feel bad about it. I also get paid over twice what is technically the hourly rate of a normal employee. This leads me to think that companies expect employees to spend half their time doing what I do when I'm not billing them -- letting ideas percolate.
Sure, I am polishing up some other projects, slowly extending them. You know the drill -- better commentary, testing for more unusual conditions, making the "pipeline" reach further in both directions, that kind of thing.
However, I have a Difficult Problem that will require something special to get me going. The last time I was faced with a similar issue (some rather geometric issues, given that it is GIS), I kicked it around for months. One night I was ill and had to take my usual medications for it, and as I became very sleepy, the solutions began to appear to me as well-illustrated diagrams in different colors, with drafting-style callouts and such, a long parade of what I had been looking for. When I woke up, I drew them out and after then, I could begin to code.
Everything else I am doing is basically pick and shovel work of coding. For this, though, I await the call from my muse.
> The revised bill arrived: $1.00 for turning the screw; $9,999.00 for knowing which screw to turn.
is preferable to
> $10,000 for building a new printing press system from scratch.
False. You may throw code away.
Also, did you visit the link?
If you put something useful up, you're stuck with it for a long time, and getting rid of it is another time investment
Coding can be purely a learning process.
Someone is furiously writing as much code as possible, and the next panel is someone else furiously trying to delete it as fast as possible.
Someone stayed up all night to rush to complete something after someone asked for a feature, and then the next day they find out that guy didn't even work there.
A team spends 5 months refactoring their webapp to force it to fit into 512mb, and then in their final presentation someone asks, why not just buy a 2gb stick of memory? https://thedailywtf.com/articles/That-Wouldve-Been-an-Option...
Some programmers are much more valuable to their employer than just for the code they write. You don’t become a 10x engineer (if such thing even exist) by writing 10x more code but you can enable others and make sure things work and easily deliver multiple times more value.
Good managers understand this very well.
Instead of sitting down and writing a draft code version, then reworking it, then reworking it again, then realizing there's a better way to do/structure the same, discarding it and making a clean version I was forced (by the baby-centric lifestyle) to think it all through in the head first. I would then sit down and emit the final version on the first try. The best part is that it also took noticeably less time than the iterative "hands-on" approach.
1. I am in the 5th meeting to discuss the details of a 10-page document about a feature that would take 100LOC to write if we weren't using Spring.
2. I am waiting for a dependency manager that is incapable of resuming downloads to download my dependencies from the private repository of dependencies which is located overseas, and my ISP has shitty QOS to that location, and the company's dozens of network and infra people don't think it's worthwhile to set up a proxy on this continent. Or I am using wget to download the dependencies and manually moving them into the dependency manager's cache on the filesystem, which is still slow, but more certain to eventually succeed, since wget can resume downloads.
3. I am learning in my 1:1 that if another developer on my team has attempted to set up some alerting, and our QA has signed off on the alerting, and our SRE has signed off on the alerting, but the alerting is not actually working, it is my responsibility to ensure that the alerting is actually working before my manager learns that it is not working. So I should just do all the work that nominally belongs to my teammates all the time, and delegating tasks is some fake thing to make others feel good, not an actual way to designate a DRI for an objective.
> delegating tasks is some fake thing to make others feel good
Somebody has to ultimately be responsible though right? If you're a team lead, isn't it still your responsibility to make sure the work your team has done is actually working before you tell your manager that it is?
Why am I not doing that right now? Because I'm waiting for some of my mistakes to get enough heat into the wood stove so I can leave it to its own devices and head to the shop.
If I wander HN in the same mental fugue state, I often find things that save me effort later.
The unfortunate reality is that developing roadmaps/managing stakeholders/building team collaboration takes a large amount of time.
Arguably 90% of this effort could be eliminated if the number of stakeholders was reduced, or the company exercised more trust that their engineers were working on the right things. There is a tremendous amount of waste introduced by the endless tracking of engineering deliverables.
This theoretical world would need code monkeys and not engineers
Who is paid to write code? I'm paid to ensure my team delivers quality software, on time and to spec. Typing out code is the least difficult part of that.
If we include the whiteboarding and sketches, I'm coding all the time! If we're talking about literally inputting code, well it's because it's very difficult to solve hard problems without some sort of planning first.
Also, administration of issue trackers, etc. Meetings. Helping a coworker. Writing documentation. Waiting on a response from a 3rd party vendor, etc.
Maybe it is similar to working from a different place? (e.g. coding sitting in park instead of the same old office day-in day-out)
Another example is "productivity apps". I was using one for ~1 year and it was going great until the last few months. I simply changed to a different one and now I'm using it much more than I was. I think just changing the stuff you use all the time is something that is under-appreciated
Most likely that will build momentum.
Can also try accomplishing a small not-work task like laundry or something to solve it from the other end. (You’ll feel like you can take on bigger pieces because you just accomplished something)
Lastly reading the specs or playing with the app with no other windows open and eventually boredom will take over and you’ll start making bits of progress.
The larger system you work on, the larger fraction is spent on non-coding. I happen to work on a source base of ~14 million LoC.
So I’m not coding until I get promoted. I got a raise and a promotion last year, did about 2 weeks of work to give the management the marketing feature they wanted, and now I rest. I’m currently holding out on another marketing feature because the management has no choice but to go with me (deadlines, talent challenge, budget challenge). So I’m using my skills as leverage to earn more.
I told my VP that this feature can’t be delivered until I’m made a Director.
Good luck!
I only code productively between the hours of 10 pm and 4 am. If the baby sleeps.
Morning coding time is spent fighting with my inner manager about how to present last night’s work at standup.
Afternoon coding time is spent in a stupor wondering why the coffee has no effect anymore.
I do try and find time to code on the weekends, but the pandemic has all but destroyed my motivation to do anything beyond the bare minimum.
1. I'm simultaneously filling out performance feedback while supporting infra and a team who is developing said tool.
2. I go to merge code from said team to fix a UI/UX issue of decent urgency. Looks good, builder succeeds, deploy to staging quickly to confirm before going straight to prod. Deployment fails. Odd. Check, odd errors. Turns out JFrog is experiencing an outage and that's a dependency on the builder, keep that status page open, go back to actually filling out performance feedback.
3. Get some unusual flakiness on the performance tool, don't think much of it.
4. See update from JFrog, they are down due to a GCP outage. I go to GCP to see what services are down, and Cloud SQL (the database the performance tool is on) is experiencing issues.
In summary, GCP goes down while dealing with a bug in a performance feedback tool that I am both in the middle of using and also assisting with in a non-coding capacity. There's some non-coding for ya :)
- I am currently not coding because I have a profile running, to figure out which part of the code I'm working on is slow before fixing it.
- Shortly after pandemic lockdowns, I was not coding because my employer had a problem, and we could only come up with two solutions to it. Both were very high-touch, in the sense that either would require hundreds of dev-hours divided across at least a dozen individual developers. I was not coding for about two weeks there because I was the one tasked with doing an inventory of all that work, so we could make an informed decision about which solution to pursue.
The other way of putting this: The job of a software engineer is not just (or often even mostly) coding.
Yesterday I was not coding because my simple change required a bloom filter. I spent a little time finding an appropriate package. I went to import it and my IDE couldn’t. Now I am trying to find why the the manifest is borked, decided to re-pull all dependencies from scratch, find out three of them are incompatible, so I have to figure out what version to pin them to, etc. One lib had a breaking change in a patch version that I could address in our code. Cool, now back to using a bloom filter...
And our integration tests are more and more brittle as we put more and more services into our docker compose files. And they take longer and longer.
You don't usually get overtime or benefits, so working more than ~120% time sets a bad precedent. (It's good to do right by your clients, and people appreciate not being specifically billed for small things)
Setting aside time to not-work is a good hedge against getting over-committed, especially since individual contracts can ebb and flow in the volume of work required.
Also, do you realize exactly when you are asking this question? It's two days before Valentine's Day, and a Friday evening for most readers. I know this is Hacker News, but I'm kind of surprised at how tame the responses are.
Is this really the norm? I was under the impression that charging 30+ hours can easily happen. Especially if the contract is for longer term and it's practically a mini-employment.
Only slightly exaggerating. Still, it's no fun being stuck between loving to code and building virtual machines with my own hands, and loving to lead teams and drive projects and see the amplified output of a group working together.
Coding has the seed of burnout. Not everybody ends up burning. Most people control it. Some people build barriers to contain it. Some people develop intrincate kinds of neurosis. Some people use drugs. Some blows up.
Dealing with machines is frustrating. Dealing with humans too, but machines are more difficult to hate. The printer scene in Office Space is hillarious just because that.
However, customer meetings are exempt, so the time previously taken up by meetings with co-workers is now used by sales and project management to "improve communication" about the customer needs or to "give them higher visibility" into our (non-existent) progress.
I'm coordinating another devs too and that costs less time then meetings to projects. We don't have the best product owner culture, so I need to fill that role too. But we are working on that topic atm and we are reaching the first goals.
It's funny and I like it, but sometimes I just block time in my calendar to do tasks two weeks ahead. So nobody is able to schedule me on a meeting without asking before.
That makes most people think about if I'm really necessary.
But honestly the fact is the sheer complexity of the problems I'm looking at requires so much thinking. That complexity wasn't there in the older days. There were also a lot less people involved in a project and that causes added complexity, in fact, exponential complexity to most changes in code, since code has become product.
Code is now of biblical importance. In the olden days, it was about getting things done. Today, you write code that could make or break the company. People judge you on 5 lines you've written 6 months ago within thousands of other lines; the more experienced you are, the more ways you can implement something, with many consequences compounded by who's going to use it and how within the next 5 years.
So, a lot of my time is spent making sure I give my team something they can work with.
—
Another one is that our dev environment is broken. Our developers have a bad habit of deploying their local branches without integrating the latest version of master. And suddenly the UI devs are twiddling their thumbs because someone has to run a 20+m deployment to get it back up to date.
1. On StackOverflow learning more about how C# works under the hood to understand memory/CPU usage (newer to C#, used C++ in a past life)
2. Building/debugging a spreadsheet in Excel (not a software engineer by job description)
3. Debugging software issues on hardware by messing with the hardware
4. Thinking about how to code to solve the problem; drawing/writing things out, etc.; rather than just diving in head-first (need to do this more...)
On monday, I will git pull the repo and add some test the team needed to write, but had no time to code.
1) I can't concentrate with the sound of this dickhead next to me eating 5 times a day.
2) You keep asking me why my ticket isn't done yet
3) I'm troubleshooting this other problem for a customer that I'm for some reason supposed to do concurrently with my assigned tasks.
4) I'm not interested enough in creating what is ultimately a html/css page, but that has devolved into a complex state management, component architecture, strict typing, and build system monster.
5) Meetings, though the last place was reasonable about them for the most part.
If I were to try and answer why I would be coding, the answer would be that the problem is sufficiently complex or new to me, and I have the mental and physical space to tackle it. Every one of the above 5 are constants in most workplaces, and it burns me out to the point where I don't know what compels me to keep seeking jobs.
For me, it is definitely schedule anxiety. If I have meetings throughout the day (I do), forget it.
Why aren't I coding? Because it's the middle of the day. I'll get going at 7-ish. Or tomorrow, when everyone else is taking their kids to the park.
Why aren't I coding? I have perf reviews that need to be completed by Wednesday. I HATE PERF REVIEWS! Unable to function.
Why aren't I coding? I have to do a presentation next week. I HATE PRESENTATIONS! Running on zero sleep. Unable to function.
Why aren't I coding? Because we are hiring. Always. Damn. Hiring. Non. Stop. Interviews. Please make it stop.
Why aren't I coding? I already have 4 changes out for review. My git skills aren't good enough to keep stacking these things and keep them straight in my head. I'll rewatch The Expanse while I wait.
I feel this way because over a year ago I began a project in the hopes of answering a single question. Every day I am looking for information that might help me answer that question.
Some people would argue that I should stop trying to answer the question and instead try to test things in code. That the process of coding will help me solve the problem. For this problem, I disagree. There is so much I don't know that sitting down and testing things feels like a waste of time. I refuse to program until I have the structure of the program cemented into my brain. Not every single little detail, just the big picture.
When I program, I am chasing an idea. And if I don't fully understand that idea, then programming it becomes so much more difficult.
I still think it took too long to complete some tasks. They would occasionally bog down while I had to noodle with existing code to be able to add new features. So even if I'm coding, I may not be creating value but rather I'm paying down the company's technical debt.
In other words, I'm not working on The Real Problem, I'm adding a feature.
Sometimes it will be coding, sometimes it will be asking questions, sometimes it will be thinking, etc...
The more senior I become in my career, the more I realize that less is more, with coding. There is no thinking tech debt.
I rarely write any code myself these days (and when I do, I make sure I'm not doing that in any critical path of the company).
Barely just enough to stay sharp to remain an effective tiebreaker and stay respected by a highly capable team.
Mostly prototypes, tracer bullets, idea scribbles and PoCs.
Other than that, I focus mostly on distributing knowledge, connecting the dots and lay the tracks forward to make sure we as a team build something that creates value for the company and doesn't have to be thrown away.
Writing more code myself would be a dire waste of company resources.
Not only they reduce the team output (pairing is acceptable because you're doing a pull request review at the same time, mobbing has a driver and someone helping around and the rest of the team barely follow along), they are also incredibly draining and I can't bring myself to do much more when the session is over.
I tried to raise it as a problem but we want to standardise practices and "be more collaborative". We're getting culture mandated from above and they hired an agile coach.
On the one hand, everybody wants people who can write code and keep them at the highest productivity level and on the other hand, code writers seem to care about not writing too much code, because all that new code must be maintained and might create necessary problems in the future which need to be solved :-D
I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
I am a scientist, paid to write papers, grants, and a summary of my PhD.
Now why am I not writing the grant?
Because I would rather write code
Since then I’ve learned it’s best to spend more time on a whiteboard or notepad than to jump straight into an editor - measure twice, cut once!
Most of the problems to solve involve multiple teams, and getting timelines and interfaces right takes a fair bit of talking, drawing and writing. Once that's done the coding is quick and simple
I'm not paid to code though, coding is incidental to the engineering
I have to break through all these barriers to get to spend a minute after work writing code. Before pandemic, would happen like once every other week, maybe. Now it's like once every three months.
It's February, it happens. As manifestations of seasonal depression go, it's really not bad, compared to spending a month wishing I wasn't alive.
Been keeping up with exercise, eating right for the most part, seeing friends a little. I'll get through it.
I can't drop out of my job to start working on them because people rely on the money coming in from my current job which consumes all my time and energy. I could try to raise investor money but as I said, I don't know how to monetize these ideas or at least keep money coming in so no good investor would give me money and I refuse to commit fraud.
* various political machinations behind the scenes
* the gutting of the team I'm on
* the sunsetting of the project I'm on
* my contract coming to an end
The temptation to just browse reddit, twitter and youtube is one I'm struggling to resist.
Waiting for units tests to run
Finding the perfect Giphy to slack my colleagues
Fetching coffe
Installing OSX updates
More seriously, I'm continually getting interrupted with support cases, and my head is destroyed.
I'm being paid whether I write code or not, so there is that.
I know ultimately I want my own product. A simple, niche, probably boring, product that myself and my wife can maintain, and ideally - pay for our living expenses. That's the big shiny goal.
My agency (of 8 years) was acquired late last year, and I'm currently a little burnt out. I have so many ideas, a smattering of self-doubt, and I think deep down a bit to prove to myself.
So at the moment i'm taking a break, and focusing on something a bit left-of-centre (for me at least).
I am writing all my experiences of starting and running a software agency up at https://devtoagency.com . It's oddly cathartic, and as somewhen who has never written before I am finding it a mixture of fun, exciting, nerve-wracking and again - sometimes self-doubt inducing.
For the first time in my life I am also part of a community (on Twitter). I am conversing, and helping new developers, and it feels good... It's not all about "me", and I think that's what I need this minute.
This just turned into a weird self-help exposé ;)
TLDR; I am focusing on helping others through writing and community building.
You're imposing your own incorrect assumptions about what developers are paid to do.
007 films
tl;dr: not my KRA anymore.