(Disclaimer: I'm building up material for https://whyarentyoucoding.com/)
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!).
Because Coding is not Working. Coding is not Planning. Coding is not Being Efficient. Coding is not Accomplishing Goals. Coding is not Saving Money. Coding is not Gaining Customers.
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).
Just in case you aren't aware, but this is what agile is actually about. Big part of it is communicating with the team. Not having a fixed plan and adjusting when having new insights is also part of it, but I think the communication part is often overlooked.
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.
Why do you have to ascribe good practices such as confirming work necessities as being “Agile” or not? The word (as a proper noun) to me has lost all meaning having been inane different workplaces, all of which claim to be “Agile”.
I've also witnessed agile being used as a excuse for "We're not going to take the time to understand the problem. We're not going to work with the client so that they understand their own problem. Nah. Insted, just do the work. Do what you're told. If we miss the target we'll fix it in another sprint. They're paying. NBD."
Actually, because I also feel that the word has been used in many contexts and I would like to sharpen the meaning. So you might say, that I could go around an find all things that work aka good practices and say 'This is Agile', but in fact Martin Fowler (one of initial authors), said, that they even discussed calling it 'Conversational' but ultimately choose 'Agile' [1]. I think that example shows, how important verbal communication is, from the perspective of the Agile Manifesto.
Perhaps. But methodology should be independent of being able and willing to ask questions. A close colleague recently left a company because the talk was "we're agile" but the walk was "don't ask questions, just do what you're told."
> But methodology should be independent of being able and willing to ask questions.
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.
You are 100% correct. This is why Acceptance Criteria are a thing: so the person working on the ticket knows exactly what it means to be "Done". If they're unclear, they must be made clear (by questioning as you did).
Often, unclear description or Acceptance Criteria means that the ticket hasn't been though out properly and needs to be clarified (or scrapped).
Not to dismiss your point, but I'd like to add that simply adding an "acceptance criteria" section to all tasks also isn't a solution.
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.
Many of the process improvements we have made where I am over the last ten years boil down to "ok, stop, does this still make sense?" at each hand off. It helps that we make data driven decisions so the stakeholders know what they need rather than "yeah, can you make me a button that doubles or revenue?"
Well, make sure that's actually wanted before jumping into assumptions.
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.
> 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.
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.
I dunno, if one of my team members was constantly coding up non viable prototypes instead of communicating with people, writing up proposed solutions and alternatives, and seeking a bit of consensus first, that would strike me as a much worse waste of time.
Prototyping takes less time than writing up the requirement in paper. And customers can give more accurate feedback watching the prototype than reading the docs.
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.
You aren’t writing up UX requirements. You’re writing system designs.
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.
> it becomes more and more important to plan before you write.
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.
Sure, but a few days of intense dedicated discussions /white boarding with a handful of senior engineers can save you from throwing a bunch of different prototypes at a wall to see which one sticks.
Controversial as it may be I completely agree. Maybe I’m just not on the same god tier level as the rest of you but I have done the days/weeks of planning carefully without touching anything close to code “because you’re not supposed to” and there still ends up being things we didn’t think through that become obvious at implementation time. I agree that coding and planning don’t have to be mutually exclusive
The thing is engineers in other engineering disciplines have documentation that lay down things to the minutest detail. So is it not a good idea for software specifications to do the same, instead of having a brief design document missing huge amounts of design details.
Abridged and abstracted documents add their own confusion.
> it becomes more and more important to plan before you write.
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.
Well this is obviously also bad. It is not necessary to either dogmatically code without first planning or discussing, or to dogmatically write a fully specified and unchangeable spec. There is a huge continuum of possibilities between those extremes, which strike a better balance than either approach.
> 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.
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.
Prototypes are useful when you already have a pretty clear picture for what you're trying to build and just need to figure out how it's going to work. If you have yet to validate that you understand the what, you're better off talking and whiteboarding than taking time to code up a prototype.
Yep, the answer to this question for me is pretty much always "because I'm communicating", followed closely by "because I'm reading". Coordination and research are a bigger and more important part of my job than coding (which is also important).
If you look at the referenced website, you'll see you're taking the question pretty seriously. To the comic author: I think your work is funny, keep it up!
> There are many reasons why not doing X is right, including social/mental recovery and prevention of burnout.
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.
Interesting how judgment is assumed in this question. A question like “why aren’t you living in Istanbul” feels very neutral, whereas OP’s question can feel like a moral suggestion. Seems unfair to presuppose such things, though especially in a caustic way
I'd definitely also treat a question “why aren’t you living in Istanbul” as non-neutral with an implied assertion that in the absence of any specific argument it the natural choice would be to live in Istanbul; it's pretty much the nature of any question in the form "why aren't you doing X".
This is a bad analogy. Coding is closer to writing a book than building a house. The faster you start hacking prototypes the better. As long as you are ready to throw virtually all of it away. Most of you assumptions during planning are wrong anyway so there is little point in planning too much.
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.
I think you’re right but that doesn’t mean the questioner is naive or inexperienced. It’s a legitimate question with lots of potential interesting answers.
Coding is part of working but not the full story. Problem solving (especially analysing and designing) is the most important part of the work. To do good work you think hard, solve the problem, and then code the minimum necessary to make it work outside your brain.
I write better non-trivial code when I get up and get away from the screen for a while. Go do something else to get my mind off it. Even sleep on it. Then the insights creep in. Hammering away at a hard problem usually makes a big mess. Sometimes three quarters of my time is spent understanding the requirements, negotiating the solution, researching, talking through the design.
Same here! Sometimes I’ve spent weeks thinking through a problem fully, talking to everyone involved (including myself) only to code whatever it was in a couple hours. It’s amazing what our brains can process subconsciously.
Related to this, I typically advocate for the daily stand-up close to mid day so that more work gets time to "sleep on it" and then a chance to add any insights that came to you during the off time. I seem to do better features and code over two work sessions than in one long continuous day.
You don't think that coding a prototype in a few hours before talking to people would let them better answer your questions and help reduce that time to a few days instead of weeks? Coding is a very versatile tool and can be used to greatly improve communication.
If it's a very specific problem and you have a candidate solution already known, sure. If it's a vague problem or if you just don't know how to solve it, a prototype would do much less, and is probably a waste of time.
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.
> Hammering away at a hard problem usually makes a big mess
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.
Coding is a good way to explore the solution space, but not the best or only way.
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.
For me, coding is a great way to explore the solution space when you're down to the last few details. Because coding is implementing a concrete solution, exploration in code tends to only cover a very small subset of the real solution space. On the other hand, if I take a few steps back and look at the problem from a wider angle, I can often find a solution that is both better for everyone and easier to implement.
It's possible the question is meant as "in the context of wanting to code and having something to code, what is impeding your desire and goal to code at the moment?".
Look up "tracer bullets" in the Pragmatic Programmer. Basically you create an end-to-end working system that capture just enough functionality to work, then you show the user and use their feedback to adjust your "aim" for the next version. Rinse and repeat. I've tried this and worked pretty well.
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.
I am paid to solve problems, programming is one part of that, thinking about the problem and the code is a prerequisite to programming. Sometimes one needs to step back and let things sink in rather than continuous action (programming)... while doing that you can even play games, I'll admit some activities are better than others for the purpose of de-focusing your subconscious - but sometimes you also just need a short mental break, that's often when I go to HN.
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.
> 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.
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.
It's a good point, but, to be fair to parent commenter, they may have meant something different.
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.
Yes I hope my tone was fair, I didn't want to be too cynical. There is definitely a spectrum between "overworked, burning out" and "love my job and sometimes I think about it at home too".
One way to not care about the arbitrary thresholds set by 9-5 is to happily not think about work during those hours, just as much as you may think of it while falling asleep.
How do you not think about work outside of work though? My current job is a shitshow, and I would like my thought towards it to only happen 9–5 while I get paid, but my brain is always thinking about whatever I’m stuck writing code about even during my weekend or outside work hours. I don’t work outside work hours but I can’t stop the thinking either. You make it sound like there is an on off switch, but I don’t seem to find mine. Do you have any tips?
This technique helps me break a thought pattern. I ask myself (regarding my situation where I physically am right now and then expanding outwards to my life)
“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.
Definitely not an on off switch, it took me ages to get better at turning work off. I think the only advice I can give is to make sure you have non-computer/software hobbies, and practice being more mindful in general. Being mindful lets you get better at noticing when you've got yourself in a work/stress hole again. Thinking about work is involuntary most of the time, you just end up there, but if you can train yourself to notice it you can hopefully get better at stopping it.
"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."
Came here to say this. Coding is one part of the job but mostly what I get paid to do is solve problems. I've worked on projects that were more process oriented and produced zero code whatsoever and still had the sort of outcomes good software does.
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.
> 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 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.
That period of time between 5 and 9 the next morning is actually there for the mental break you mentioned before. I'm not advocating a very strict separation between work and free time, but if the line between the two blurs too much (made easier by home office), your work might completely invade your free time, which isn't good either...
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 :/
While off topic I’d echo this for managing coders as well.
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.
I finally checked out the link. You're looking for material to use in a comic? And I'm trying to give you a serious answer. Maybe these experiences will help:
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'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 know this is going to date me.) I used APL before and during college on a terminal with a type ball. (https://en.wikipedia.org/wiki/IBM_2741) APL is a great language.
> I generally think that if I can't find a good name for a thing, I don't actually know what it does yet, so Im not ready to code it.
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.
This reminds me of advice I learned in school for writing: if you are having trouble coming up with an introduction, just write as if you already introduced the topic and come back to the intro afterward.
Mainly because I’m helping other people be able to code. One of the interesting things about the 10x engineer meme is that they’re 10x because they improve the productivity of their team. Well extend that to DevRel and that’s maybe another order of magnitude or two of effect again. Extend that to the average person looking to build and it’s another order or perhaps two again. Hopefully the stuff I’m doing now will get ten people off the ground immediately (I already know it’s reached at least this many people) but another 1000 going this year and another 10,000 if not more going over the next two years.
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 10x engineer being an enabler is a nice interpretation but the original definition of a 10x engineer is a skilled engineer working unhealthy hours.
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.
I worked on a team with a 10x coder, who was 10x because he improved the rest of the team. Would jump in when people got stuck and unstick them by seeing the yak immediately, where others would just work their way up to it one stack frame at a time. Had a better knowledge of the strengths and weaknesses of everyone on the team than they did, and knew how to nudge them towards the work they would excel at without making them feel incapable of the other work. Would unstick people by finding out how they could help other people who were also stuck and vice versa. He got promoted to manager after basically doing managing the way it should be done, without us ever making us feel like we were being managed. And it really was a golden time for our team. Except he quit not long after. Not sure why, but I suspect management brought along a lot of other responsibilities (interfacing with accounting, HR, higher-level management, etc.) that he didn't really enjoy.
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.
One would presume that 1x is the baseline for 'competence', which is fine, but being able to do something competently vs. making it worse is really an infinite difference.
This isn’t valued everywhere. I worked at a company where doing that kind of work (piling more hacks on top of what’s already there vs taking a step back and seeing if there isn’t a better way to do it while slightly improving what’s already there) was considered over-engineering things and actively discouraged.
I'm constantly bombarded with "quick" questions from coworkers about how some part of my code works (or more often why it doesn't). After several such interruptions it's harder and harder to even try to focus, maybe some kind of neurosis, fear of being interrupted once you are again in flow?
I've been in the same situation and I found the solution was to do less. Unblocking coworkers is valid work, and spending more time on code so that they're not blocked in the first place is also very useful. By doing that I found the overall team velocity went up even though my personal point count fell.
If you are on a team, we’ve addressed this by having a single dev responsible for all incoming questions in our team channel. Any DMs are directed back to the team channel for the designated on call person.
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.
Ehh, mine are typically very valid, specific and informed questions. I'm blessed with very smart coworkers, but we are seriously understaffed and documentation is lacking. When you "own" very big lightly documented system, questions happen.
I’ve been there before. Would recommend starting a document and answering the questions there then linking people to the doc after you’d added their question/answer.
The habit of check the docs first and maintaining docs in this way is really critical for remote teams and bandwidth.
I'm not coding because I'm reading a webcomic about why other people aren't coding.
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.
Hang in there bud. I kinda have the same thing as well, hobbies have helped a bit with burn out. Glad your at least trying to get help. Again, hang in there.
It is probably roughly analogous (I do consulting but not specifically coding), but much of my "down time" truly is "letting the ideas percolate" because properly thinking through what you're planning to do slowly and methodically saves you so much time and frustration in the end.
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.
Mentally spent, in the back of my mind I have this feeling like "why aren't you accomplishing something" but I just literally can't. I can't even watch tv or something I'm just in a bad mood in general today idk what to do, kill time till I fall asleep. Wake up with a fresh brain and then do the hardest thing first. In the end... it is just passing time... I guess I'm lucky I at least have a job that pays... what I build isn't Uber or something you know it's just like a self jerk "look at me I made a todo list" kinda crap.
Don't beat yourself up. This is a video I come back to all the time for inspiration. It's probably the most important youtube video I've seen. I'm hoping it resonates with where you're at.
Currently, I am waiting for inspiration to strike.
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.
Code you write is code everyone will now have to maintain forever, so naively, you want to solve problems with as little code as possible, and maximize the value being generated by your codebase. So you should be spending your time on... properly validating the business value of your projects, properly designing what a system should look like on paper, properly considering use cases and edge cases, finding what code can be eliminated, finding what code can be refactored, finding the single line that you need to change to make it all work.
> 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.
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.
I'm not coding because there are more important things to be done. For example:
- I have to groom tasks and interfaces across team boundaries.
- I have to review others code.
- I have to help someone with their problem so they can proceed and deliver.
- I have to onboard.
- I have to make sure processes are working well.
- I have to make sure the team works well.
- and so on and on...
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.
Because I’m having an existential crisis thinking how incapable I am and have been winging it all along. Keep stressing over how long would it be before they find out and kick me out.
Been through this and in retrospect this was a blessing in disguise.
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.
Not quite this, but I think the enforced discipline of parenthood has made me a better worker overall. My ability to procrastinate hasn’t been eliminated, but every moment available to work feels more precious so I’m much better about just jumping in and getting things done. I also have hard stops and self imposed deadlines like I didn’t before, so I’m more efficient in “just getting things done.”
The last time I was paid to be a developer by a company, the most prominent reasons I was not writing code were:
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.
> it is my responsibility to ensure that the alerting is actually working
> 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?
Because I build furniture now and I'm much happier for it.
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.
In a theoretically optimal world, all engineers would have immediate and omniscient knowledge of all dependent teams, and stakeholders interests. They would also have immediate knowledge of all system complexities and have no operational burden or customer's that they need to help. Of course in this optimal world engineers would always have instant access to all knowledge of their toolchain and not need to perform research, and the build would of course never break.
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.
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.
I'm paid to write (valid, working) code. If I sit all month just thinking but no effects, I will be fired. Of course, thinking about what code to write is a big part, I've spent twoo weeks once not writing code and the result was changing one number from 4096 to 8192, which made one shitty iot device a little more stable, which was seen as a big success. So, I wrote 4 bytes/2weeks, most of it was thinking and finding what to change, but essentially it WAS writing code.
I'm always amazed at people who think that programming languages and typing and editing are the hard part of what software engineers do. I spend much more time trying to understand the problem that I'm trying to solve, and to make decisions about how to do that in a way that I won't regret.
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.
One of the best software engineers who worked for me was the guy who deleted the most code. He absolutely produced negative net lines of code, and it was a running joke that we were paying him to write code, but he was doing the opposite.
Because I am working on another team's code base and my code merges are dependent on their whims and schedule. Submit pull request, wait for one week for somebody to review and give feedback (all of which is bullshit nitpicks about spacing, one style of unit tests over another etc.), implement the feedback, wait for another ten days for the same person to review again and provide another round of more bullshit feedback. In the meantime, my boss says you are not coding enough to get promoted to the next level. I have started doing LeetCode because I was concerned that I might forget coding and also it will help me find another job.
I was in one of these for a few months. Strangely enough, changing all my editors color schemes from darkmode to whitemode helped me to overcome it. Over time I went back to darkmode for the most part.
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)
I definitely can second this, changing something about my tools can jump-start stuff.
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
The trick here is to break it into the smallest possible pieces and just start doing the first piece as your only task for today.
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.
I'm most comfortable coding in a unix environment, but I built/bought a windows computer to play video games on, and I'm too lazy to either install a linux distro on here, or setup a dev environment using WSL, etc. Also, I don't really have any projects in mind that are grabbing my fancy.
I was in a similar spot, except with the addition that I gave up on installing a Linux VM/WSL because my gaming laptop came with Windows 10 Home (which doesn't support Hyper-V) and I didn't want to shell out $100. However, recently I gave it another shot, as WSL2 apparently works just fine on Windows 10 Home, and I was surprised how easy it was to set up. Took me less than an hour to get WSL2 set up and hooked into VSCode with all my preferred settings. I recommend giving it a shot next time you have some inspiration.
What about using vmware workstation to run a Linux VM? i find it useful to keep dev stuff separate and have a disposable OS when i install too much junk.
I’ve discovered that using my coding skills as leverage against the management class is the best way to earn more.
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.
Working on a project that is being wound down due to lack of sales but the remaining tasks are asinine compliance requirements imposed by the new parent company - we have been acquired recently - that are "non-negotiable" even when the project is going to be sunset soon. Management also is dragging its feet in finding a new project for me. Motivation to play along is low. Working from home as single is doing its own part. Management doesn't seem as isolated because they're in calls all day or have family.
I know this isn't an advice thread but 1) milk it while you're still collecting salary and 2) make sure your LinkedIn profile is fleshed out and your resume is clean and up to date 3) hit up your former coworkers to ask how their new job is...maybe let it slip you're looking to move
Profectionism procrastination:
Because I haven't figured out the best perfect solution that solves all the problems without any trade offs. I'm waiting for the perfect design to occur to me. I'm hoping it might occur to me while working on something else, reading blogs, watching youtube, in the shower, or while I'm sleeping. Or, I'm waiting for inspiration of any kind. Or, I'm waiting for an idea that intrigues me enough, or that I might learn something from, that I think is worth attempting.
"because I'm compiling the kernel for the 8th time, waiting for my manager to ask me what I'm busy with so he'll know I do a job he can't. Witch kept me hired so far" ( not from me, yet true )
Actual experience I had recently that could work here:
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 :)
The most common reason I'm blocked from coding is that I'm still doing the analysis necessary to figure out what needs to be coded. Examples:
- 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.
Busy talking to people, splitting work into issues, writing the issues to put on project boards, finding which project board to use, searching for which issue I'm working on, searching for which project board I put it in, updating project boards, starring at the 150 crap email filling my inbox everyday, writing filtering rules for my inbox, double checking if I didn't miss an important email, looking up unread Slack messages, following up on unanswered questions, getting up to drink some water, getting up to piss that water, taking a break to eat lunch, dropping my daughter to the daycare, picking her up from the daycare, making coffee, ordering coffee beans, reading up documentation, reading code, reviewing PRs, writing code.
When you do contracting, you outline a maximum number of hours you can charge. It's usually <=20/week for any given client if you have high rates.
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.
> When you do contracting, you outline a maximum number of hours you can charge. It's usually <=20/week for any given client if you have high rates.
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.
Because my title includes the word "Engineering Manager", which means if I code people will think I'm a shitty manager who should be an IC. So instead I'm required to write a bunch of docs and attend meetings, and explain ideas to smart developers who don't quite get it the first few times... but once in a while I'll crank out a demo to show the team the way, quietly fearing my career advancement opportunities diminish if my own leadership finds out :-)
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.
I take you'd better read an honest answer about what makes people avoid positions where there's much coding in favor of others rather than some joke or anecdote about why I'm not coding right now.
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.
Because my boss's boss has sent down a directive that there will be NO MORE MEETINGS. This then requires every manager to meet with everyone they have ever talked to (not just their direct reports) to explain that there will be no more meetings.
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.
Meetings, most of them without bullet points or a specific topic.
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.
I'm stroking my beard and thinking hard about a problem, trying to sink back into some kind of productivity about being interrupted 3 times in the last 10 mins. Probably stretching my back, feeling the tiredness in my shoulders, noticing my coffee has gone cold, thinking about the next cup; with an added sense of regrets for the wasted time and gut wrenching sadness about how fast I used to be at programming.
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.
I’m gathering requirements. Since all my projects are badly under (or over) specified.
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.
because im vacuuming the db, flushing the cache, rotating the logs, retrieving the stats, rebooting the server, teaching you to change the background in the chat, commenting on the tickets, adding to the docs, onboarding the noobs, upgrading the libraries, adding ips to the firewall, updating the ssl cert, installing, compiling, backing-up, migrating, doing my timesheets, ive got 3 'training modules' i haven't completed yet, 5 invites to a PMs weekly catchup I cant make, I've been asked to review the spec on some other project, still need to setup the VPN access, get passwords for the VNC, need to email support to put my keys on the new server so i can jump host as working remotely, editing crons, editing configs, security updates, replying to client emails... oh and that line of code i wrote this week. sadly I had to write that as there was no other solution. I mean I googled like fuck for ages but this is the only way.
"i thought you said some other guy had done it already on github and all you had to do was tweak it."
"na. it didn't work the solution ended up being these 2 solutions on stackoverflow that i copied and pasted together."
"you're a genius."
"thanks"
Writing a proposal for a customer in the millions range.
Not coding; but figuring out if we undestand well the rewquiremente, figuring out what has to be done, when, how, and whay kind of problems might arise (imagination is important, and beigng pessimistic, too).
On monday, I will git pull the repo and add some test the team needed to write, but had no time to code.
The last time I was employed, almost a year ago, my answer would have been one of the following.
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.
Love the comic! Sorry about all the people replying without visiting your comic.
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 code at work and occasionally on quick personal tasks. I consider myself as someone who isn't coding enough.
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.
At a previous job, I was asked to write up a list of my accomplishments for the previous year in preparation for my performance evaluation. During the evaluation my manager and I went over this list and I commented that it seemed to me that I hadn't accomplished a year's worth of work. He as happy with my work but acknowledged that there were a lot of things I did that wouldn't go on the list and I can't be expected to be producing all of the time. I suppose that's like focus factor in Scrum.
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.
I'm not coding because I don't believe the work I need to get done will fix the issues I've run into while trying to get my work done, and it's hard to find motivation in that situation.
In other words, I'm not working on The Real Problem, I'm adding a feature.
As a JavaScript developer I am paid to use enormous frameworks. Solving problems or returning value back to the business are often (not wanted) beside the point. Attempting to program real solutions in this line of work frequently results in hostility from your coworkers.
Because I've realized that for the things I want and need to build, I would be an order of magnitude too slow to go alone.
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.
I once worked at a company that, when they did sprint planning, counted a day as 4 hours, that is to say if you said a ticket would take 4 hours you were saying it would take a day. Which means that any 8 hour day was half not coding.
I feel like I'm just doing it for the greens ya know ? I started programming 'cause when I was a kid, I always wonder how the things I love like games and software that I used to use works. But since then, I found myself in need to earn money to keep life going, and that curiosity and possible passion has to turn a way to live and survive and, I confess, it's starting to lost its bright, there was a long time ago since I code something to myself; but this year I'm planning to change it, I don't want this passion to die and become something bored.
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.
It is funny to read all the comments and see the dichotomy of coding:
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
Because I'm updating my work log. Because my employer wants me to keep a log of everything I spend my time on. Or, because I'm updating my ticket statuses. Because my boss wants to see updates in tickets periodically even if there is no progress, so sometimes the udpdate is just "no progress."
When I first started, I thought I would by touch typing code all day long. It was within my first project I realised we were there to solve problems rather than hacking at a keyboard.
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!
I find I have a limit to the number of hours I can code per week. Sometimes I'll spend a weekend on a side project or fixing some bug. When I go back to work the next week I just have trouble being productive. Same if I work late I can get stuff done, but tomorrow's productivity will suck.
There are multiple ways of solving a problem and sometimes more code isn't the answer. Taking a few days to properly analyse a problem, examine the existing codebase and weigh up various alternatives is vastly superior to going in guns blazing and creating a giant mess in the process.
Depression and medication side effects I'm still working through. There's an intense fog that forms in my head when I try to think through a problem that didn't use to be there. Even problems I've solved before I have much greater difficulty with than I remember having.
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.
most of the things I want to "code" have problems with them I can't solve. I don't have the time or money to solve those problems so why start? I have some potential business ideas/big projects but I can't figure out how to make those things pay for themselves and some of the engineering requires solving problems I don't know can be solved.
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.
I'm spending less time coding now, but still writes more code than ever before. That's because I'm getting better at my craftsmanship. The issue is what I'm doing when I'm not coding.. meetings, chats etc. Total waste of time if you ask me.
Too much time and work involved, but the problem with buying software is you get too much bloat and poorly coded stuff despite having more features. Even if you are an amateur, coding it yourself can produce better results than even off the shelf stuff.
I was asked to document old code, which someone else had taken over before leaving and removed the framework standards while I was on another project. They renamed every file index.js,and now the cli tools don't work.
I'm very much an amateur, and unless I have a project, I don't really code. My projects are generally configuring various WMs or Emacs, or weird stuff, like Gemini browsers, an abortive clicker game, et al.
Because in a sense I'm being paid not to write code. Company put me on furlough due to budget problems, but are paying the remaining 20% of my salary, so I'm basically being paid my full wage to not work.
I'm not currently coding because running a company, talking with customers, learning to build hardware, solving electricity and magnetic problems. Coding maybe every second week.
Coding requires prolonged intellectual focus. Prolonged intellectual focus brings insanity. I dislike insanity, from top to bottom. Therefore I no longer code. Not much, anyway.
Writing JIRA tickets, meetings, running SQL queries to prepare reports for X number of reasons, on call operational work to keep our systems running, writing design documents.
My hands have hurt too much, continuously, ever since the operating systems course at Carnegie Mellon in 2008. The doctors claim they can't find anything wrong.
Because my compiles take to long - just noticed this. My compile takes a minute or so, so I flick to hacker news, reddit etc while waiting, then what was I doing...
Nothing! Since quitting my job and becoming self-employed, there are now no bosses or coworkers or anything else to stop me from coding (except HN of course!)
I'm busy learning art. All of the things I want to make (mostly games) will require good art, so this is as good an opportunity as ever to focus on 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.
I don't think the system I use it on even has anti virus. What I mean is after I do a code change I have to remove all packages from the server, clean the server, run a build, add all packages to server. All of those take minutes.
I got promoted to tech lead for writing good code and now I have subordinates who wrote shitty code which I have to review. So I don't get to write code myself.
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.