A day in the life of a software developer

Yourself isit

lmimmfn wrote: »

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.

It's easy enough to sell bug fixes to customers actually. Tell them the next Q release is to fix as much technical debt as possible). Of course this is harder but not impossible with ancient code bases.Throw in some performance fixes and you can sell it.

However service delivery and product owners don't always want to sell that.

Skommando

The golden rule you have to get used to in software development is that there is never adequate time or resources given to do something right in the first place, but an endless amount of time and money is then thrown away fixing and maintaining the mess you are then stuck with for years afterwards.

Skommando

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.

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

aka "if it ain't broken, we'll make sure you keep changing it until it is"

lmimmfn

Yourself isit wrote: »

It's easy enough to sell bug fixes to customers actually. Tell them the next Q release is to fix as much technical debt as possible). Of course this is harder but not impossible with ancient code bases.Throw in some performance fixes and you can sell it.

However service delivery and product owners don't always want to sell that.

Its not the norm though, if i buy product A i expect it to work, i wont pay extra for it to do something it was supposed to do in the first place. Service contracts however are a different ballgame.

Skommando wrote: »

The golden rule you have to get used to in software development is that there is never adequate time or resources given to do something right in the first place, but an endless amount of time and money is then thrown away fixing and maintaining the mess you are then stuck with for years afterwards.

I disagree with this....in a way, if the implementing developer is responsible for giving the timeline of implementation then maybe with a 20% time overhead it should be delivered in close to perfect state( or stated beforehand it will need to be productified afterwards, proper unit and integration test cases are generally 66% overhead on top of general implementation from my own experience ) . If however you throw that out to a bunch of random ability developers with agile in force then yes, expect $hit to be delivered.

Skommando

lmimmfn wrote: »

Its not the norm though, if i buy product A i expect it to work, i wont pay extra for it to do something it was supposed to do in the first place. Service contracts however are a different ballgame.


I disagree with this....in a way, if the implementing developer has any input into the timeline for implementation then maybe with a 20% time overhead it should be delivered in close to perfect state( or stated beforehand it will need to be productified afterwards, proper unit and integration test cases are generally 66% overhead on top of general implementation from my own experience ) . If however you throw that out to a bunch of random ability developers with agile in force then yes, expect $hit to be delivered.

that's one very important if you skimmed over, and if your aunty had balls she'd be your uncle.

lmimmfn

Skommando wrote: »

that's one very important if you skimmed over, and if your aunty had balls she'd be your uncle.

lol, youre right.
Generally devs are not given enough time or have little to no input on time estimates even if "agile", its like dev says it will take 2 weeks to implement, product owner says we have only 1 week. Its released, its a mess and they spend 10 times as much effort fixing it up.

It depends on the devs though, if i give an estimate, thats my estimate, if they want it sooner( which i havnt had a problem with in years ) they can f*ck right off.
Im not trying to be an ass though, if i get some guy out to fix my boiler and he says it will take 3 hours i dont ask him to do it in 1.

beauf

Graham wrote: »

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

Often it shouldn't be the business either.

The Business often has the budget and resources, to build a Cessna, but they insist on the Space shuttle. Likewise the developers often launch into development without understanding the business requirements either.

Bane of my life.

Yourself isit

lmimmfn wrote: »

Its not the norm though, if i buy product A i expect it to work, i wont pay extra for it to do something it was supposed to do in the first place. Service contracts however are a different ballgame.

Most people don't these days even for software products rather than services. They fully expect to be downloading fixes every few months. Or new content. Service contracts are probably more common than software products these days and it should be perfectly easy to get bug fixes into that schedule - where or isn't is because of weak product managers.

I disagree with this....in a way, if the implementing developer is responsible for giving the timeline of implementation then maybe with a 20% time overhead it should be delivered in close to perfect state( or stated beforehand it will need to be productified afterwards, proper unit and integration test cases are generally 66% overhead on top of general implementation from my own experience ) . If however you throw that out to a bunch of random ability developers with agile in force then yes, expect $hit to be delivered.

I agree about agile bring no magic bullet, and that it makes things worse by encouraging the man month fallacy.

Graham

beauf wrote: »

The Business often has the budget and resources, to build a Cessna, but they insist on the Space shuttle. Likewise the developers often launch into development without understanding the business requirements either.

So the space shuttle gets separated out into it's individual components and estimates are put against them. It's then back to the business to decide on the priority of each element.

Yourself isit wrote: »

I agree about agile bring no magic bullet, and that it makes things worse by encouraging the man month fallacy.

There are no magic bullets and most common implementations of agile at least attempt to get away from the hours/day/month based estimates.

lawred2

lmimmfn wrote: »

Its not the norm though, if i buy product A i expect it to work, i wont pay extra for it to do something it was supposed to do in the first place. Service contracts however are a different ballgame.


I disagree with this....in a way, if the implementing developer is responsible for giving the timeline of implementation then maybe with a 20% time overhead it should be delivered in close to perfect state( or stated beforehand it will need to be productified afterwards, proper unit and integration test cases are generally 66% overhead on top of general implementation from my own experience ) . If however you throw that out to a bunch of random ability developers with agile in force then yes, expect $hit to be delivered.

100%

But you can expect a lot of self congratulatory backslapping from management for having adopted/imposed 'agile'

As if saying it automatically delivers quality

beauf

Graham wrote: »

So the space shuttle gets separated out into it's individual components and estimates are put against them. It's then back to the business to decide on the priority of each element...

Yes they will decide the want to build the shuttle in the time and cost commiserate with a Cessna.

Fukuyama

OP, I've only been a developer for the best part of 6 months. Still in my first role post-college so I imagine my experience will be similar to yours (being the newbie).

For the first few months my day was pretty much this:

Arrive into work at 9am. Grab a coffee. Check slack and email. Respond to various emails if they're important. Respond to various slack messages if they're funny. Check tasks assigned to me on job tracker. Most days there was some kind of standup / team meeting. Great time for me to mention if I was low on work - if I was another dev would usually grab me to burn down some of their tasks/bugs.

After that, normally fixing bugs or implementing small features under the supervision of a more experienced dev / lead. I actually really enjoyed these as it was a non-overloading way to get used to the codebase and also get used to writing unit tests that were previously ignored. Spend most of this time alone at my desk working quietly which I love. It's a very quiet office. Only time I really interact (other than Slack) is when chatting to another developer if I needed them to throw an eye over an issue I was having.

If I ran out of bugs I'd just annoy another developer for more of their small tasks and try do a good job on them. Only ask questions if you've at least put some effort into resolving the issue yourself. Generally I tried to at least present a possible solution which was usualyy 80% of the way there.

Lunch at 1. Always take the hour. I noticed a few people do seem to work through lunch most days. Seems to be voluntary, as others have said. After lunch more coding. As I'm still new I estimate I spend 70% of my time coding.

After that it's home time. I've only ever worked late once and it was voluntary. I just 'needed' to figure something out myself and fix the bug so I stayed late by maybe an hour. Didn't even notice for a while because I was stuck deep in the task at hand.

I was made permanent after my internship ended. Still spend most of my days coding (Javascript and Python, via Angular and Django respectively). Love it. Want to get into some native Android projects next year as I miss Java. I enjoy being able to actually like my career. However I've learned to not let some facets of the job get to me:

1. At times I do feel pressured to 'just get it done' by a non-tech manager. Usually when there's an emergency caused by a previous 'just get it done' solution. I write good code in work but the codebase as a whole isn't something I'd call a well oiled machine. It can be frustrating when you have to build something which you know damn well isn't up to scratch and will be cause of headaches for months to come.
2. I still get the most enjoyment from programming when working on my own personal projects or studying at home. The Github has been ignored. Thinking about contributing to a few open source Java based projects I've found. Also Raspberry Pi FTW!
3. Unit tests will save you so much time down the line and people will like working on your code better.
4. First few months I was knackered at the end of each day. Couldn't look at a computer when I got home in the evening. That's tailed off now. I'm 10 times the developer I was when I started and it's exciting to think about where I'll be in six months.

MillField

Skommando wrote: »

The golden rule you have to get used to in software development is that there is never adequate time or resources given to do something right in the first place, but an endless amount of time and money is then thrown away fixing and maintaining the mess you are then stuck with for years afterwards.

An unfortunate reality in my experience. Development driven by the customer. :mad:

Graham

MillField wrote: »

Development driven by the customer. :mad:

Life would be much easier without customers?

MillField

Graham wrote: »

Life would be much easier without customers?

Haha! Totally

cython

Graham wrote: »

Life would be much easier without customers?

Potentially NSFW
:pac:

Dave0JV

With me a typical day goes like

8:45 Arrive in office
10:15 Daily standup
12:15 Lunch hour
17:00 Home time

Some days I would also have sprint planning meetings or story sizing sessions lasting half an hour. Other than that the rest of the time is spent picking stories off the backlog and completing them.

Elessar

It's fascinating to read the replies here from devs who work in, obviously, proper software development houses. I wouldn't call myself a bona-fide software developer, but I do some small-medium sized development work. I work for a large company in a (depending on the day) 50% support, 50% development role. There are no standups, basic requirements, no code reviews etc. If I get tasked with a dev job I just knuckle down and get it done, get some testing done with the customer (customers are all internal businesses) and then signoff and release. And support from then on. Once it works no one cares how its done. We get a lot of bigger dev jobs done by contractors who come and go, but there's no standardisation and they are free to code whatever way they want, leading to issues with us permanent staff trying to understand their programs when it comes to support or additional development. Probably not the best environment to be in long term but it's low stress.

I don't get many dev jobs as I would like but when I do, I enjoy it.

When I'm on a software project a day would be like:

8.00-09.00am - check emails, respond, check ticket system for incidents/requests
09.00-12.30 - Work away on the project, answer support requests
12.30-14.00~ - Lunch
14.00-17.00 - Work away on the project, answer support requests
17.00 - home.

I support a wide range of software so I can get pulled in different directions depending on the day but generally very little meetings.

beauf

Elessar a lot of places I've worked are the same. My current place is exactly as you describe. While easy going I have to say I find it frustrating. If you have experience of doing things properly. Also I miss genuine innovative solutions rather than small incremental changes. Its quite inefficient.

gaillimh

Would ye lads generally have fixed lunch hours (I.e it must be from 1-2pm)?
Just curious.where I work they introduced a half hour lunch so you can leave a half hour earlier in the evening then if you like.
It's optional though so you can take an hour if you want.
Also quite flexible - I generally take my lunch at different times every day depending on hunger level, work schedule, meetings, errands I need to get done at lunch etc.

Are your companies flexible at all?

TrueDub

gaillimh wrote: »

Are your companies flexible at all?

Totally - eat when you want, for as long as you want. Most people take 45mins or so, others vary depending on workload or desire to leave a few mins earlier.

robbiezero

lmimmfn wrote: »

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

You would want to love it if your working nearly 12 hour days 2/3 times a week. Not a hope would I be doing that with your amount of experience bar I was getting very well recompensed for it.

beauf

gaillimh wrote: »

Would ye lads generally have fixed lunch hours (I.e it must be from 1-2pm)?
Just curious.where I work they introduced a half hour lunch so you can leave a half hour earlier in the evening then if you like.
It's optional though so you can take an hour if you want.
Also quite flexible - I generally take my lunch at different times every day depending on hunger level, work schedule, meetings, errands I need to get done at lunch etc.

Are your companies flexible at all?

I don't think I ever worked anywhere that wasn't flexible. Core hours, outside of that do what you want.

Senna

Core hours 10-12 2-4, do your 7.5 hours around that, but they like you to start between 8.30 and 9.30 and be finished no earlier than 4.30.
30 minutes lunch, but it's flexible.

I also go to college (related but not through my job) on a Wednesday morning, so I work 2-10 from home on that day, handy that I can do it.