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.

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?