Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How much code do you write in your job?
18 points by gosenx 4 months ago | hide | past | favorite | 45 comments
How much do you write code in your job? I have 4 1/2 years of experience and I have never had a time where programming was 60-80% of what I did and I’m very frustrated about this.

The whole point I started programming at 16 was to get a job were actual programming would be the main thing.

Tell me your experience and what kinds of programs you work in or industry if you find relevant.




I am the most senior technology person in a <20 person startup and I do a pretty even 50/50 on code vs non-code tasks. It's not very stable though. Some weeks I'll be on calls for 30+ hours, others I'll be locked in the dungeon and pushing hundreds of commits. Really depends on where we are at. I am actively trying to get out of code duty because it's really hard to manage the overall tech strategy when you are 20000 feet deep fighting some ancient balrog for days on end.

After doing this a while, I realized that writing the code isn't the part that takes a long time. It's rewriting it over and over because you didn't fundamentally solve what the business was asking for the first time. I prefer to focus on that part of the puzzle now. Making sure it gets done right the ~first time. Help others on the team avoid lava pits that they can't see yet.

I try really hard to avoid writing any code until I am nearly certain how something should be implemented. Exploratory rabbit chases are quite rare for me these days. A younger me would be appalled, but I enjoy a new kind of game - Making the customer happy for minimal effort and then getting paid.


Sounds like a lot of fun. I work as Platform Engineer so I’m also on call for about 30+ a week sometimes. The only thing I don’t get to do is programming a lot, I mean I do write some Terraform, YML, Go, scripts etc but not the type of coding that you spend a month building something rather than small programs to automate and facilitate our ops work.

I want to shift from ops to systems programming and find a completely new role.

I’m really good at the debugging and diving into new codebases, but companies don’t like the fact that I don’t really have a previous full time coding role.

Happy to ear how things are going for you and how you have grown technically.


I am also in the boat of wanting to switch to systems programming. Writing code in Terraform or YAML is soul-sucking to me, but sadly all I get currently. I have previous, full time software engineering experience, so I have “seen the light”, making Terraform/YAML feel that much more like a punishment.

I’m building up Rust skills (1 year in now) to make the jump once that’s more popular. It’s a slightly risky bet (Rust jobs are currently 95% crypto).


I'm doing the CTO thing for a <10 person start-up that is actively building our initial product. I am rapidly and randomly switching from anywhere from 0-80% coding during any given week depending on what my team and the company needs. Probably closer to 20-30% on average.

I come from a history of being an individual contributor (15 years of that) and I would say overall as I've gotten more senior in my positions I've done less coding as a % of my time, but the coding that I have been doing is individually more impactful or sensitive.

The non-coding part of my time has gone more into mentoring, reviewing, design, business discussions & goal setting, policy writing and implementation, team organization & management, and interactions with operations.

I think that about covers it, but feel free to follow up if you have anymore questions.


I’m sure that being an IC for 15years helped you develop the technical sharpness that allows you to make decisions and do deep dives occasionally.

I want to be in the 70-90% of coding now because as I improve and move up I will not have had a stretch of deep programming experience.

If you can think of anything, what would you advise me to do?


My team is pretty small right now so yes I do end up doing a fair amount of technical decisions but at my last spot, I was more of a head engineer over groups of engineers and I really need to learn to let the teams below me make their own technical decisions only stepping in when there was a conflict, they were explicitly asking for guidance, or in a few rare cases where I could see they were clearly going down a wrong a road.

I think I would need a bit more information about your current seniority and skill levels before I could give you more specific direction. There is always the default answer if you want to move up higher that communication skills are important, and that's true but what I don't see as often is developing the skill to let decisions go and to not only find ways to live with them but actually accept those decisions and move forward with them.

Absolutely speak up if you disagree, and communicate clearly the prior experiences that is helping guide your decision. Talk about your assumptions and where you think future pitfalls might be. If your team or manager decides to go down a road you don't agree with or don't think is optimal... Let it go. Work with it. Try and accept that as a path forward and embrace it. You might not have the full picture, it might be a legitimately better strategy, or you might be right. In any of those scenarios though fighting against the current, trying to go rogue to prove your path is correct. Those will only lead to ill-will. If it does turn out to be the wrong path, don't play the "I told you so card", take the high road and just move forward.

A lot of engineers, myself included, look back at prior decisions more than looking forward. Reflection is important, and lessons can be learned but we're there to build things, not be right all the time. The bigger your team the bigger and more intense things you can build, but only if you're all working with the current of development.

The more you work with your team, the more they trust you and as you gain in seniority you will have a peak of silent "I told you so moments", that's usually when I've found it was time for me to go up to the next level of seniority as its probably time to start mentoring the people around you.

None of this is about getting more coding time, but I don't think I've ever really optimized for that. Maybe think about what you're trying to get out of that coding time. Maybe what you're actually looking for is unbroken focus time, that I have optimized for but also involves working with your team. Communicate with your team that you would like more focus time, propose things like protected afternoons (meetings only in the morning) or meeting free days (I've found Tues/Thurs usually work best for this).

If you provide me with a bit more detail I might be able to give less general advice.


I’m currently a mid-level SRE engineer cornering the senior level. My goal is to reach the principal/distinguished levels.

I’ve found myself in the I told you so moments in my team and have had an informal heads-up about a promotion. It’s too soon to even be talking about this, but I hope it gives you enough context as I’m looking forward to you advice because your last comment was really really good. Thank you for taking the time.

I’m not in Silicon Valley or any other tech hub, I’m in a small country in Africa and want to put a dent in the engineering world. A cliché I take very seriously :).


I work on OpenTofu since November, lots of coding, docs, the rest is helping the community or coordinating contributions.

I used to work for Red Hat (OCP on oVirt/RHV, Arcalot/Arcaflow, etc), in a little over 2 years I wrote somewhere around 40.000 lines of code that I can account for with 80%+ time spent, but that diminished greatly around the end as a lot of changes into the "Scrum to rule everything" direction happened, which decreased the amount of code produced by a lot.

Depending on what you do you may want to go window shopping for jobs where coding skills are valued and that are low on process. If the interview process already puts heavy emphasis on your code, that may be a place for you. If, on the other hand, the quality of your code isn't appreciated as long as it works... Smaller companies/projects tend to work better.


Ohh I’m jealous of you. I dream of coming near that number this year on my personal projects.

I’m in the market looking for something in the intersection of infra/systems programming.

It has been tough to get interviews due to my location and experience, but I know I will manage to do it.


Don't give up! It took me a while to get things going too (I've been in the industry for 15-ish years and only started figuring out a bunch of stuff in the last few years.) Also, there are plenty of remote jobs that will happily do a B2B contract with you unless you are in one of the handful of countries that the US has problems exchanging money with.

I can only speak from my experience, but what helped me land interviews ( as a gradually built up over the last 3-4 years) was:

- Having contributions in high profile open source projects name-dropped at the beginning of my CV. (Front-load the interesting stuff. Also, these should be substantial works in case somebody goes to check.)

- Having relatively well-known open source projects I built from scratch (ContainerSSH, gotestfmt, etc) in my CV with well-known users I can also name drop. These projects had nothing to do with my day job and I built them in my free time.

- Having spoken at several conferences. This is the most unfair of all since not everyone can travel and having the conference in there doesn't say anything about the quality of the talk, but it seemed to help get through the recruiter filter.

What helped me get through the interviews (again, from my experience):

- Having experience in diving into unknown codebases and problems. Most companies that are serious about coding will have you do live coding, take home exercises, or read some code in the interview. If you do enough work on open source stuff, you'll develop this automatically as you will be jumping into code that's not yours.

- Being able to do TDD in the live coding interview and still finish on time. Nobody I talked to actually does hard core TDD in the industry and most people are stuck with a ton of legacy code, but this is a magic trick that will get you some eyebrows raised assuming you don't mess up the rest of the interview. Also, forget algorithmic problem solving. While at least knowing algorithms and datastructures helps, most companies don't have deep algorithmic problems in their day to day operations, so encountering these in the interview I found to be a minor red flag.

- Knowing the language basics. If it's Javascript, know your type issues or how the runtime works. If you do Go, know parallelization problems and how to solve them.

- Structure your code! On the interviewing side I had to fail too many candidates for submitting code with an unclear/messy structure for take home exercises.

Big no-nos (when I was the interviewer):

- Do not claim you contributed to a project if all you did was a typo fix.

- If you have a Github profile, make sure it's not full of forked repos you didn't contribute to. I will only look at what you linked in your CV, but others will google your name (no matter if it's illegal or not).

- Clean up or set your social media to private if you don't want interviewers to see that. Google yourself, make sure there are no red flags there.

- Don't use ChatGPT/Copilot without heavy refactoring. This is incredibly easy to pick out and not cleaning it up, not making the code style consistent screams that you have no idea what you are doing. Remember, interviewers only have your code to go by as a signal source.

- If there is a woman in the interview panel, make sure you don't just address the guys. We did interviews with my wife and we noticed this a lot. This may just be a force of habit, but for companies paying attention to diversity, this is an immediate red flag. The people who got flagged for this usually turned out to have a culture fit problem in other areas too, but it's worth keeping in mind.

- Leave your ego at the door. They may criticise your code, but don't get defensive! Stay factual, that will help defuse the situation.

- Don't have typos in your CV. Use a spell checker.

Finally, really, don't give up. My experience is just that of one person, I (probably) don't live in the same country, probably don't have the same amount of time available as you do, and I (probably) don't work in the same area as you. My advice may be complete garbage and not applicable to your situation.


You really motivated me here. Thank you. I'm planning to getting into containerd and kubernetes.

I will have something to show for by the mid-year. I'm sure. Thank you.


Fun fact: I had only a rudimentary understanding of Kubernetes until 2020, but I had a fair bit of knowledge about containers. (Built an experimental container engine to learn.) Then I did 2 Kubernetes certifications and that got me up to speed (completely useless apart from the time spent studying). In the process I went and adapted Kelsey Hightower's "Kubernetes the hard way" to my then-employer's cloud offering with Terraform. It was super hard because everything was different, but totally worth it. Would absolutely do it again.

I built ContainerSSH at that time too to learn Go (look up the first versions, it's ridiculous how small they are) and then went to work for Red Hat with my new found knowledge.


Ohh the more you write the more inspiring it gets. You cleared my thoughts towards what to do, I'll act on it. I checked you website and OSS work, really good stuff


I'd say 85-90% of my work these days is programming. Both the actual coding and thinking through problems or architecture decisions, benchmarking, testing/comparing approaches, etc.

It really depends on the position and nature of the responsibilities though. I've had position where at least half my time was meetings, and others where there was just a lot of Slack chatter to work through during the day. Right now I'm on a limited-time contract with a very specific project to iterate on and finish up, so I don't get pulled into peripheral company decision meetings, 1-1s, etc as much. This appears nicely conducive to programming time.


I think I will have to find something to do on the side because everywhere I went with that I thought I would program a lot I ended up not doing much programming.


I work at a hedge fund, and I spent 98% of my time writing code. I usually work on 2-3 experiments simultaneously, and every day or two take 2 hours off to work on "zany schemes" -- moonshot type ideas that occasionally are very lucrative, and therefore justified time-wise.

1 meeting a week, for 1 hour.

I work 3AM to 11AM, then about 12:30PM to 6PM on my side gig https://atomictessellator.com


Out of curiosity - are you working in NZ?

What software stack you're using at hedge fund?

Can you tell how many lines of code did you commit in a first week of December? :-)

Not asking, but asking - what is your hourly rate? :-)

Congrats on side gig - interesting idea!


> Out of curiosity - are you working in NZ?

Yes

> What software stack you're using at hedge fund?

Cant discuss

> Can you tell how many lines of code did you commit in a first week of December? :-)

43 commits, 3440 lines added, 374 removed

> Not asking, but asking - what is your hourly rate? :-)

Wont discuss with strangers

> Congrats on side gig - interesting idea!

Thanks! It's heaps of fun and it's only just started making new discoveries, time to lab-test some soon


Like 25 years ago I dreamed of visiting NZ :-) Never been there, but still want to learn to perform Haka! :-)

Thanks for answers!

That is hell a lot of the code for one week! About software stack - how do you post job ads if you can't say what you're working with? :-)


NZ is nice but it’s too small, I live in the biggest city, and the Python community is very small, and culturally NZ pretty barren being such a young country.

I lived in Germany, Spain and the UK for the last 10 years and it was much better - but had to return here for family.

It is nice to visit though! Make sure you try bungee jumping!

We don’t post job ads :)


^ just to clarify, I work from home in NZ but the company I work for is in USA


similar here, except I'm in PL


How much can you get done in 2 hours for the zany schemes?

Do you use any software methodologies?


it’s not solidly time boxed, sometimes it might be a whole day, if something is yielding positive results, everybody here is very senior so we all have a good intuition for which rabbit holes will yield

Software methodologies for the zany schemes? Not really, I prefer to do exploratory code inside the debugger (I wrote my own which has a bunch of extra extensions) and the others use Jupyter to riff freely, there’s no constraints when exploring

More engineering rigour goes into prod stuff


Depending on the type of project, sometimes 70% of the time is programming and 30% is consulting with the team. Other times I do 60% design and 40% programming. It's project by project. For me, most projects are greenfield development. Some of them don't even come to fruition after weeks of designing and are lost. The main thing is to do your job the best you can.


How far into your career are you in? I imagine that it is frustrating to see your efforts go to waste.


I have been programming for over 20 years. I've developed everything from small in-house applications to systems in critical infrastructure... But the working mood and work deployment depends mainly on the setup of the internal company policy :)


My title is director of product development. I manage a team of roughly 30 people with 1 layer of management between most ICs. While it’s not evenly distributed, over the course of a year I spend about 10% of my time writing code. I’ve worked in strictly development roles before where I was still coding less than 50%


How did you grow? I imagine that to become a director one must have had a very good IC career and accomplishments.


Solo founder; it tends to change rapidly depending on the stage of the product.

Probably 90% of the time writing code currently. Once the hardware product is released publicly it drops to 10% (maintenance) and then ramps up when new significant features are added.

Broadly speaking..

Stage 1: design specs 0% code

Stage 2: prototyping 50% code

Stage 3: the hard work 90% code

Stage 4: selling and maintenance 10%+


Fun y you call it the hard work. I guess you mean hard as in, more "physical" so to say. The. Doing part is the easy work and flows well. The debugging and figuring out what do to solve problems is the hard part.


The figuring out and doing are the easy part. The hard part is breaking up your work in a way so you have something for the daily standup to talk about.


About 80-90% at the moment due to project work where I'm (currently) the most experienced/knowledgable person on IaC in the company.

A few colleagues are learning very quickly so looking forward to taking a step back and focus on other things in 2024.


I'm fortunate enough to work for a small company with a tight group of devs. We have daily stand-up and I'm pretty much left to research and code for the rest of the day. I'd say I code about 80% of the day.


almost at any place that rate is not really stable over time and overall if you have something close to 65-70% then it's probably just average situation.

From my experience places where more programing happening are: - mid-big companies where you role could be very specialized - small companies with focus on creating tech products or where tech has lot of impact on end customers (like if fixing few bugs could instantly lead to making additional money for a company)

Companies from non-tech word usually value non-coding stuff much more.

(I currently have about 50/50 rate and sometimes even less)


Nearly 100%, the other time is spent planning tests, discussing new features with users. I probably spend 90% of the time actually coding.


Are you self employed or working for a company?


Technically, self-employed but working entirely for one company.


Almost zero. I refuse to classify YAML as code.


It's code, you're just not allowed to know what language it's written in.


If it's not a marketable skill it's not. I'm getting out of the door as soon as I get an offer.


Agree and understandable. No one puts YAML on their CV. You do put the overarching technology there though. Say, kubernetes. Configuring that can be a marketable skill.

Another place are CI/CD pipelines. Some jobs seem primarily about that, which I always thought extremely odd and boring. In that sense, the DevOps style of work is truly defeated (developers writing their own pipelines).


Thanks. I'm actually a data engineer but the org is removing Python and Scala from the picture while a data platform team develops a YAML-DAG solution and our team has been the experiment subject for the last 12 months.

I can't imagine being an engineer without writing a single line of code. I'm done.

And Yeah infra is being taken care by the other teams too. But the strange things is, whoever wrote the infra or YAML solution NEVER bothers to daily-manage them. We as the user have to fill in a lot of mundane stuffs. For example they never bother to get permissions for us, we have to do it by ourselves.

Anyway, they get the fun we get the shit. I'm getting out. I heard a lot of big corporations are like that, e.g. I watched the Netflix videos but they all make me shiver and unwanted to work as a DE UNLESS I'm in the platform/tool teams who develop those fancy things, otherwise I'm just a YAML monkey.


You just have to find the right company and role. I have always been able to get out of meetings by "focusing on being an IC"


A metric shit-ton!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: