A day in the life of a software developer

Hollister11

I'm a future software developer, currently in 3rd year of college studying computer science. Hopefully starting an internship in Febuary.

I want to know what is the typical day in the life of a software(or web developer)

punk_one82

Depends on a company by company basis but a lot of software dev jobs are in Agile(or what they think are Agile) companies. So you'll have a daily standup at some stage, possibly a few other meetings here or there, coding, debugging, googling, listening to music and depending on the company maybe some pool or foosball for good measure.

Manach

Half the time project work, quarter emails/meeting and remender ad hoc work. Training /upskilling done in own time.

Seth Brundle

Get used to not taking a lunch break!

henryporter

kbannon wrote: »

Get used to not taking a lunch break!

That's the biggest impediment to productivity right there - you might as well finish at 3 and go home if you don't take a lunch break, go for a walk and freshen up both the mind and body. No job is that important that a half hour to get out in the fresh air is not acceptable or achievable

TrueDub

kbannon wrote: »

Get used to not taking a lunch break!

Entirely company-dependent. I've never worked anywhere where you couldn't take your lunch break. Most of the companies encouraged you to take it, as a refresher.

Seth Brundle

TrueDub wrote: »

Entirely company-dependent. I've never worked anywhere where you couldn't take your lunch break. Most of the companies encouraged you to take it, as a refresher.

I'm not saying that you can't take one. But there can and will be days where you're on a roll or you are going to/from a meeting or whatever and don't take a lunch.
Equally you could be working late.

maki

kbannon wrote: »

I'm not saying that you can't take one. But there can and will be days where you're on a roll or you are going to/from a meeting or whatever and don't take a lunch.
Equally you could be working late.

Again, company dependent. The worst I've ever had was a single instance where I had a half hour lunch break instead of an hour due to meetings.

So while it can of course happen that an individual's lunch break gets wiped out, saying "get used to it" by implying it's an industry norm is misleading.

brevity

Hollister11 wrote: »

I'm a future software developer, currently in 3rd year of college studying computer science. Hopefully starting an internship in Febuary.

I want to know what is the typical day in the life of a software(or web developer)

If you are on a project and if there is a requirements doc, this is what you will be working to. You may be called into stand up meetings to discuss blockers and the general status of your work.

Alternatively a senior developer might assign some small tasks to you. This could be front end or back end.

Also, you might be assigned some simple bugs to fix - this is a way of getting you used to the dev environment.

Dante

I think this breakdown is about right:

50% moaning about dodgy requirements specs, 40% stuck in 'stand-ups' which last far too long, and 10% Googling/coding.

14ned

Hollister11 wrote: »

I'm a future software developer, currently in 3rd year of college studying computer science. Hopefully starting an internship in Febuary.

I want to know what is the typical day in the life of a software(or web developer)

None of the other answers I felt were particularly accurate, so here's my take after twenty years in the industry.

My typical day in any of the roles I've worked past ten years:

* 50% of my time goes on dealing with (note I did not say fixing) bugs in code written by others long before I joined. Most of that code was written under huge time pressure by insufficiently experienced people, and has poor testing, poor use of standard algorithms, and very poor "copy & paste" design. I also frequently see a lot of unnecessary complexity from NIH syndrome, often from people who were ignorant of what the programming language, standard libraries and tooling is capable of and could have eliminated 80-90% of the buggy verbiage they wrote.

* 30-40% of my time goes on admin: attending meetings, scrums, email, teamworking, peer review, mentoring etc. The more senior and experienced you get, the less time you actually write code and more time you spend in admin of some form.

* 3-5% of my time goes on writing new code of my own design, usually under severe time pressure where I have had to rush and skip a lot of due diligence including writing good testing.

* 5-8% of my time goes on fixing bugs in code I wrote. This percentage grows the longer you stay in a role, and it's the most enjoyable part of my day because usually you aren't under severe pressure to get it done as fast as possible. You usually also get a chance to refactor the earlier rushed implementation and add better testing and it's much better for it.


A lot of fresh graduates get very disheartened a few years into commercial employment because most of your day is meetings or doing whatever fire fighting JIRA tells you to do each day. Companies like to throw away your work too which doesn't help morale either. You get very little scope to take the right engineering choices, almost all the work you do is on some legacy codebase which is barely working and if they just threw it away and redid it everyone's productivity would jump several fold.

But a long time ago I stopped worrying about any of that. Put your bum in the seat for X hours, get paid. It's great pay for being effectively a janitor. Go home and write quality unrushed code in your spare time. Never expect to do so in a paid employment unless you are very, very, very lucky (and even then, trust me it won't last past when your employer gets acquired by someone or goes bust, so enjoy those brief periods while they last).

Niall

lawred2

DaaaaaaaaaaN wrote: »

I think this breakdown is about right:

50% moaning about dodgy requirements specs, 40% stuck in 'stand-ups' which last far too long, and 10% Googling/coding.

you must work with me

Creamy Goodness

Royale with Cheese

You'll spend your time drinking lots of coffee.

The lunch break thing I don't agree with, anyone I've worked with who has fallen into this trap has done so completely voluntarily. There is a certain type of person out there that takes some kind of perverse pleasure in being overworked. Get up and get away from your desk, get something to eat and take a break for the hour you aren't being paid for.

jester77

My day:
Into office at 9:45
Turn on PC, brew some coffee.
Check hipchat, emails
Sprint Standup up 10:15
10:30 - get a fresh coffee
code until 12:30
60-90 mins for lunch
14:00-18:45 coding
Go Home

Release stand up every Monday after sprint standup
Grooming every Thursday for 1 hour before lunch
Retro and sprint planning every 2nd Friday
Random meetings, presentations, conferences every so often

punk_one82

Royale with Cheese wrote: »

You'll spend your time drinking lots of coffee.

The lunch break thing I don't agree with, anyone I've worked with who has fallen into this trap has done so completely voluntarily. There is a certain type of person out there that takes some kind of perverse pleasure in being overworked. Get up and get away from your desk, get something to eat and take a break for the hour you aren't being paid for.

That's what I've seen too. Some people just choose to work through lunch whether there's any pressure on them to do so or not. It's a terrible habit to get into.

Anesthetize

It varies from company to company, role to role, day to day. My day could be something like this:

08:40 - Arrive at work, grab a coffee and have a smoke.
08:45-9:45 - Check emails, check Jira board for any new updates, read any project update slides. Continue working on my current task. This could be a coding task such as a user story or a bug fix, or some tedious troubleshooting issue which involves trawling though log files looking for a needle in a haystack
9:45-?? - Morning stand-up. Supposed to be timeboxed for 15 minutes but usually ends up being a discussion and going on longer.
10:00sh-12:00 - Continue with task/story/bug etc etc. During this time I could either be working by myself or intermittently interacting with other members of my team.
12:00-12:45 - Lunch. Then grab a coffee, go for a walk and have a smoke.
12:45-15:00 - Continue with task/story/bug etc etc etc etc...
15:00-16:00 - Quite often the day is broken up with meeting(s) of some kind. I could have days where half the day is taken up by meetings or have days with no meetings at all. These could include sprint planning, backlog grooming, design analysis or sprint retrospective. Depending on what you're working on that day they can either be an interruption or a welcome breather.
16:00-16:15 - Grab a coffee and go for a smoke. Maybe meet someone for a chat over coffee.
16:15-??? - Continue with task/story/bug etc etc etc etc etc etc.. There's no set time that I go home at. It could be 17:45 on a good day, or I could end up staying until 19:00. But usually I end up going home at 18:20 or so.

Brussels Sprout

I work from fro 9 - 5.30/6 every day. I take an hour for lunch, which I always get out of the office for and I try and go outside for 10 minutes to get some air in the morning and afternoon.

I'm currently working on a team that implements Scrum so I have a stand-up in the morning for about 20 minutes with my team. Every two weeks we also have sprint planning and a retrospective. At the moment I don't have to attend many meetings which is great but I do interact with my PM several times a day so he's aware of how I'm getting on.

Work-wise I use google a lot which inevitably brings me to stackoverflow which is an amazing resource. If a problem is particularly unique I may post a question myself or if it's domain-specific I'll go and ask a more experienced colleague or an architect within the company. I usually have my headphones on. If I'm doing something repetitive I'll listen to podcasts but if it's something requiring me to problem solve then I'll switch to music as I find that easier to tune out for when I really have to think).

I have one coffee in the morning and about 2 or 3 cups of tea the rest of the day. I sip on water the entire day and try and snack on fruit and nuts. I try to remember to get up every 40 minutes but sometimes I'm so engrossed in what I'm doing that I forget about it. I've been having back issues for the past year so that's something that I really want to sort out in the near future.

This is my second career and I quite like it. I find it stimulating and challenging and don't mind spending long periods of the day working away on my own. I'm naturally a introverted logical person so in many ways it's a good fit for my personality. I like the fact that there's an element of creativity to it, it's quite fast paced and unlike more traditional engineers, we actually get to implement the final work ourselves which brings its own level of satisfaction.

lawred2

Scrum meetings drive me insane.

14ned

Brussels Sprout wrote: »

I've been having back issues for the past year so that's something that I really want to sort out in the near future.

There are two parts to a healthy back as a computer programmer as you get into your 40s and beyond:

1. A decent chair. A decent chair does not cost less than €800-1000 new. Really decent chairs cost €2,500 or so. A decent chair you can work for ten to twelve hours per day seven days per week for six months and not experience any issues [1] if and only if ...

2. ... you also do properly strenuous exercise regularly. I bought an exercise bike for my office, and if you do a 20 minute power cycle (i.e. lots of sweat produced) twice a week it'll keep your back muscles conditioned and strong. Bikes are particularly good at working out the back muscles, though swimming is also pretty good. Walking or running is not sufficient.

[1] This is because a decent chair is intentionally slightly uncomfortable when sitting perfectly. This forces you to move every 40 minutes or so. They are extremely uncomfortable if you don't sit perfectly. So don't buy a chair which is really comfortable, that's not a decent chair. Buy one which is good for you.


Make sure you deal with back problems sooner rather than later. Letting it go will cost you a fortune to put right later, trust me. Good health is worth far more than money wealth.

Niall

BrokenArrows

lawred2 wrote: »

Scrum meetings drive me insane.

I agree. I really hate "agile" because no one can implement it correctly. Well at least no one in my organization.

Agile is an excuse for managements inability to make up their minds on what they want.

lawred2

BrokenArrows wrote: »

I agree. I really hate "agile" because no one can implement it correctly. Well at least no one in my organization.

Agile is an excuse for managements inability to make up their minds on what they want.

We've supposedly adopted 'agile'

It's the most inflexible bureaucratic method of development I've ever worked under..

Maybe we're just doing it wrong :rolleyes:

I'm a just do it type of person and I hate when obvious enhancements or features get 'assigned' into future sprints - why? just do the f**king thing now.. I'd have it done in a week if it wasn't for about 5 hours wasted in 'stand ups'

Dante

My senior management had the wonderful idea of adopting agile for a major part of a project we had been working on earlier this year.

Unfortunately they forgot that one little task of actually doing any form of sprint planning or management prior to starting each sprint, meaning that any new pieces of work that emerged during the current sprint - be it new requirements, bugs, enhancements etc - were put straight into the same sprint no questions asked. When the current sprint finished, any remaining pieces of work were simply carried over to the next sprint.

Said management were then perplexed at the end of each sprint at how we were actually ending up with more work at the end than we had at the beginning. We ended up with at least 10 extra sprints with no purpose whatsoever.

This went on for months, it was quite impressive how they could get such a simple concept so badly wrong.

Graham

lawred2 wrote: »

I'm a just do it type of person and I hate when obvious enhancements or features get 'assigned' into future sprints - why? just do the f**king thing now..

because developers should not be the ones to dictate the priority of a feature/enhancement to the business/customer/product-owner.

lawred2

Graham wrote: »

because developers should not be the ones to dictate the priority of a feature/enhancement to the business/customer/product-owner.

that all depends on the nature of the business.. and the developer

Graham

lawred2 wrote: »

that all depends on the nature of the business.. and the developer

I guess if it's the developers business......

14ned

lawred2 wrote: »

We've supposedly adopted 'agile'

It's the most inflexible bureaucratic method of development I've ever worked under..

Maybe we're just doing it wrong :rolleyes:

In nearly twenty years in the industry I've worked in almost every type of management style in everything from trendy startups through to staid big corporates. One thing I can guarantee you is that it really doesn't matter what management system a team uses, the very best teams have always sorted something or other out amongst themselves that suits that particular team really well. It is never some theory du jour or something standardised. It is what fits that team best, and with change in personnel the bespoke system changes to match the new configuration. The system is never imposed from outside, the team self adopts and adapts the system.

Agile, even when practised really well, has some advantages over other systems such as making management think they have more control but its biggest long term problem is that it tends to introduce legacy cruft into software quicker than other systems because of the short two week sprints, so inevitably you end up always doing small bits of incremental work which must fit into two weeks of work. That aggregates over time, and you can always see in a codebase where something was clearly rushed to meet the sprint end. Time, and time, and time again. You also see a lot of reinvention of the wheel, and lack of code reuse because it takes time to get your head into a problem and write code to solve it. Two weeks isn't enough time to research what code elsewhere in the code base you could use instead of just banging out a "temporary" local solution immediately.

Another big problem with agile when done properly is it is expensive on programming time. I don't think it's wise to spend more than half your time programming anyway, the other half should be spent on reflecting and testing design assumptions, but agile expends a lot of time on rituals which are supposed to help on reflection but I've never found do well on that in practice.

If I'm really honest, the most effective management system I've yet found is to employ a lot of very expensive top tier talent. You'll usually find they work only from home and use only email and git to coordinate with everyone else on the team. Occasionally they may employ a bug tracker, but that's for bugs, not "stories". Some really great code usually comes out of those teams, but it's sure expensive in wages (if not in whole lifecycle costs because code written by these guys has a much, much shorter debugging and QA period).

Niall

BrokenArrows

14ned wrote: »

If I'm really honest, the most effective management system I've yet found is to employ a lot of very expensive top tier talent. You'll usually find they work only from home and use only email and git to coordinate with everyone else on the team. Occasionally they may employ a bug tracker, but that's for bugs, not "stories". Some really great code usually comes out of those teams, but it's sure expensive in wages (if not in whole lifecycle costs because code written by these guys has a much, much shorter debugging and QA period).

Niall

Thats the unending battle with management.
Management would rather see 20 low/reasonably paid engineers working rather than 10 highly paid/skilled engineers even though the 10 would probably be better and cheaper.

Dont get me wrong. I dont fall into the category of the highly paid/highly skilled. But my team is ramping up to close to 200 engineers at the moment and i think its beginning to fall apart.

Management keep pushing new features rather than allocating engineering time to improving what is already there. Id love to see a release cycle where everyone is dedicated to "fixes". Performance, design, refactoring old legacy **** taking up 1000's of lines of code which can be rewritten in a few dozen lines with advances in .NET

14ned

BrokenArrows wrote: »

Thats the unending battle with management.
Management would rather see 20 low/reasonably paid engineers working rather than 10 highly paid/skilled engineers even though the 10 would probably be better and cheaper.

Management always forgets that internal coordination time rises exponentially with team size, so 20 developers expend a lot more productivity on coordinating themselves than 10 developers. As in, at least four times coordination time is spent for doubling a team's size. That coordination time comes out of coding time.

In SV that message has sunk in in places, hence trying to put together small teams of very competent people at half to two thirds a million salary each. If you can put together a team of seven truly superb engineers with a great working relationship with one another and a positive, can do culture, then you can easily outperform in total lifecycle software development costs a team of 70 good engineers and 700 average engineers.

I know Fred Brookes said all this thirty years ago, and so have countless studies since, but it's amazing how the message still doesn't reach most management. I genuinely think that they simply don't get it. People are not good at understanding exponential scaling and costs, they always think in linear terms.

BrokenArrows wrote: »

Dont get me wrong. I dont fall into the category of the highly paid/highly skilled. But my team is ramping up to close to 200 engineers at the moment and i think its beginning to fall apart.

Management keep pushing new features rather than allocating engineering time to improving what is already there. Id love to see a release cycle where everyone is dedicated to "fixes". Performance, design, refactoring old legacy **** taking up 1000's of lines of code which can be rewritten in a few dozen lines with advances in .NET

Some agile shops spend three sprints on features, one sprint on tech debt, and it's doable to persuade management to allow that, not least because it greatly helps team morale and retains workers. 25% of time on tech debt is better than nothing, but you can only scrape the surface of much tech debt in a single shot two week sprint.

One thing I will say about agile is if it is combined with throwing away and rewriting your product from scratch every five years, it's a pretty good system. At my current contract I'm currently out of sprint, replacing the build system of the team's product over about a six week period, so thousands of lines of complex and hard to maintain python and cmake 2 full of special cased logic branches are being replaced with declarative cmake 3 (i.e. it's written in a functional style) where each CMakeLists.txt file is typically three lines of cmake instead of the hundreds of lines each before. The new build system is many times faster, enables lots of new build tooling like static analysis, is enormously more maintainable and easy to understand and is generally a win-win-win-win for everybody.

Still, it took me over a year to persuade management that this was a good investment of time. Management will always take the view "it works, why waste time replacing it?" despite the fact that every developer was waiting around twiddling their thumbs twenty minutes multiple times per day to wait for build, and becoming increasingly sad and depressed about their jobs in the process. Bad processes forcing developers to sit idle pondering their lot in life is always a very bad move

Niall

lmimmfn

Fantastic Question OP, i would have loved to be able to get info like this back in the day.

In general, i think it boils down to your aptitude for programming. Im working as a programmer/Software Developer for just under 20 years, but i started progarmming when i was 10.

Luckily i've managed to avoid more admin work as i get older( have 0 interest in that ), so ~70% of my time is pure coding.

I dont think its possible from 1 day as a software developer to get an idea of whats involved, e.g. if youre on an agile team you will have 2-3 week sprints, the begining of which is Sprint Planning, ending with a mad panic at the end of the sprint to get the software released. Generally from day to day that involves team standup in the morning, coding & testing for the rest of the day with some answering emails, and the odd unplanned meeting here and there( or you may be unfortunate to spend half the day at meetings ).

I think i might have a different career to others in this thread, I worked in products initially spending a few years on each one, starting off mainly bug fixing noving on to new features etc, but you end up getting bored as coding for so long means you can be thrown on a new project and understand how it works end to end in a few days, maybe longer if its an area you havnt been involved in before( like e.g. moving from Application Server programming to Big Data where the EcoSystem is huge )

Generally i work on prototypes so i can work on maybe 7-8 projects a year and i may work with agile teams or might just work completely solo. The more experienced you get the more political it gets and you become more involved in politics unfortunately. I try to ignore that, i also reject most meetings as i give myself strict timelines to deliver software and i cant meet those if i spend half the day at randomly called meetings( some people like this but not my cup of tea ) like most agile teams i worked with do. I sometimes get asked to implement new features on some random product within a very shrot time frame.

Day to day i start at 9:30, I might have a standup in the morning, may get 2-3 "political" emails that i have to be gentle with, ill have 1 or 2 code reviews per day( could be 7-8 if im thrown on a team ). The rest of the time im full on coding( including reading docs on new tech to get it working ), i take an hour at lunch but generally i work late, maybe getting home at 8 or 9 2-3 nights a week. I hate working weekends so i keep it to a minimum.
Most of the time i get 1-2 months to implement something, have weekly progress meetings and at the end we test and verify it on a live customer site, it always goes acording to plan at least sofar lol.

In general, i loved coding when i was 10 and i absolutely love coding now, end result is i actually love my job and look forward to going to work every day

lmimmfn

BrokenArrows wrote: »

Management keep pushing new features rather than allocating engineering time to improving what is already there. Id love to see a release cycle where everyone is dedicated to "fixes". Performance, design, refactoring old legacy **** taking up 1000's of lines of code which can be rewritten in a few dozen lines with advances in .NET

i dont want to be an ass but selling a black box to a customer where the devs want to tidy up the insides provides nothing functionally to the customer so it costs a lot. New features bring in more money.
I feel your pain, its a common problem but unfortunately doesnt sell well to management. The only way ive seen it work is if you prove the cost of ownership is so high that it would save them money by doing so.