A week in the life of a Java developer is summarized in 3 sentences:
Danny spends his week coding and working on deployments, having problems on Thursday with an overnight issue but ultimately deploying successfully. He shares various links throughout the week related to technology topics. By Friday he has questions about the work he completed for the week.
DANNY\nIntroduction\nBoth Java developers at Nokia in Bristol\nTry to explain what it’s like to be Java developer in a medium to large organisation.\nBristol resembles a medium sized company.\nHas it’s own product, Nokia Entertainment\n(next) Includes music download apps\n
and Radio apps on Lumia phones, \n\na music download website\n
and Nokia Reading, an app for reading books\n
To build all this we have developers who do Java, web and windows phone.\nOf those 35 are Java developers: so not a massive number. \n\nWe’re going to describe for you one week in the life of Neil and find out how Neil spends his time.\nSo ...\n(His work time that is. You don’t want to know how Neil spends his free time.)\nFirst, a little context\n
A lot of what we say applies to all developers at Nokia, not just the Java developers.\nBut as Java developers ourselves, that’s what we’ll focus on.\nSo here they are: all 35 of them.\nThey’re organised into 6 teams... \n
Neil works on one of these teams...\n
Our weeks generally start on Monday ...\n
Neil\nStart Monday the same way every day starts, with a standup...\n
Fast, informal meeting where each person describes three things...\nWhat they did yesterday, what they’re going to do today and whether they have any issues that are hindering them\nGood opportunity for finding out what’s going on beyond your own blinkers\nNot much to report on Monday. I was continuing work on the story I’d started the previous Friday\nDANNY takes over...\nStory is piece of work that can be completed within a few days\nWritten on a card...\n
And placed on the team board...\n
This makes the work easily visible to the whole team.\nEasy to visualise progress by moving cards across the board\nOften, but not always, story will involve writing Java\nThis is Neil writing Java\n
Point out Linux (production environment) and IDE.\nTime coding split between Eclipse and the command line\nNEIL\nLots of decisions\nNo senior person writing reams of documentation describing how we have to achieve our goals\nDecide everything (within reason, no changing data storage willy-nilly)\nMost importantly, how to TEST...\n
No dedicated testers, just developers writing automated tests\nDecide the type of test (simple unit tests vs. acceptance tests)\nPractice Test Driven Development\nHelps guard against untested code\nHelps with finding a starting point\nDANNY takes over...\nWith 35 devs, can’t know what everyone is working on, \nto prevent breaking each other’s code\n\n
Central system for sharing and versioning code, a bit like GitHub\nSplit into different components\nFor a story, Neil will work on 1 or maybe 2, and his team will mostly stick to half a dozen\nNEIL\nStill too much code to keep in one person’s head. \nImportant to write clean, consistent, readable code.\nBy the end Monday I’ve finished my story ... (tues)\n
Tuesday starts with a stand-up...\n
I tell the team I need a code review\nCode review is an informal show and tell on the code for a story and, perhaps most importantly, its tests\nMike says he can review the code but also needs help with his related story\nWe agree to pair up\n
While pairing we can still use TDD\nOne person writes a failing test, the other makes it pass and writes the next test\nAllows for discussion and together we can come up with the best solution for the problem\nThis continues until we’re done\nDANNY takes over...\n2 ways of sharing, avoid just 1 person knowing how something works\nSituation sometimes described as “bus factor of 1”, ie. it only takes 1 person to be hit by a bus before you have a problem.\n(informal ways)\n
Knowledge is also spread more informally\nOpen plan, \nJust get up and talk to people\nAlso we have communal areas, \n
like kitchens for coffee, or a games area,\nPurpose is for relaxation, but encourages discussion with people don’t otherwise talk to\nNot everything is achieved sitting at a desk!\nNEIL takes over\nSo, working together we’ve got my story reviewed and we spend the rest of Tuesday finishing Mike’s story\nWe commit our code, deploy it to our TEST ENV and our automated tests all pass...\n
However, it’s the end of the day and I avoid deploying to PRODUCTION at the end of the day\nNobody wants to (or should) have to stay late fixing issues\n
\n
First thing after the stand-up on Wednesday we deploy our code into production...\n
We do this ourselves\nOur tests and deployment tools are automated\nCan deploy code to production without massive list of instructions\nReduces chance of human-error\n\nOnce in production mistakes would be embarrassing so we monitor\n
Spend some time monitoring the live system to spot any potential problems quickly\nIn this instance everything looks fine!\n
Danny\nNeil just deployed some code to production\nSomething that happens many times a day\nNot by a select group, but by whoever needs to.\nThis may seem like an obvious way to do things. \nBut it wasn’t always like this.\n
We used to deploy just 4 times a year.\n\nWould deploy everything new since the last release. \nAs a result, it was done by a dedicated team of release engineers. \n\n(next)\nMoving from this to deploying all the time is scary for a lot of people, including some developers.\n
Fear more change a running system => the more likely it is to go wrong\nAnd developers feel safe writing code, \nbut are scared to break everything and being blamed for it.\n\nAlso developers like to write code, but dislike anything that takes them away from doing that, such as deploying that code.\n\n(been good)\n
However, we’ve found that it has made life better. \nMore changes => more practice at changes => fewer issues\nFor developers like Neil:\nFast feedback. Wait 3 months = forgotten it.\nWatch closely as he deploys. Issues/changes => his change\n= more responsibility & more interest in production. \nSo Neil’s job is not just writing code, but also taking responsibility for it running smoothly in production.\n\n
No such thing as a typical day but...\n... some days I like to think I have a good idea of what I want to achieve first\nThe words no-one wants to hear when they get into the office\n
Know you’ve lost your pristine morning\nFlip into detective mode\n
All our search index servers stopped working within minutes of each other at five in the morning\n
Start going through our service metrics to work out why\nFind that our index servers ran out of memory due to our index getting too large\nWe have an regular process which tidies up and for some reason it didn’t tidy up in time\n
Turns out that the two weeks ago we’d deployed a change to the service which feeds the index\nRelease was intended to make things better/faster/stronger\nActually exposed a flaw in our logic which meant we were doing much more work than necessary and ended up growing the index quicker than before\n
\n
At this point we have no new content getting into the store so we’re working against the clock\nOnly one thing to do...\n
Test, code and test again to create a fix for the flaw\n
Fix is live within ten minutes of being complete\n
Monitor index growth in the period following the deployment\nAll looks well\nDANNY takes over...\nThat example was fixed quickly. Not always like this.\nNeed to remember\nWe’re all human, and we all make mistakes.\n\n
What’s important is that we don’t look to point the finger and blame others.\n\nAnd we follow the golden rule...\n\n
Don’t get caught by the same thing twice\n\nNEIL NEXT\n
Spend rest of day ensuring we have awesome monitoring in place and can preempt this in the future\n
Get the information on our radiator so we can’t help but see it\n
Nervously arrive hoping nothing has gone wrong overnight\nSecretly know it won’t because I already looked from home\n
Everything is fine\n
Celebrate with a doughnut (or two)\n
\n
Itching to look at something I’d seen tweeted overnight\nIt’s relevant and open-source and I see an opportunity to improve the visibility of our metrics\n
Spend a good part of the morning experimenting with Cubism\n
These four servers are supposed to be identical\nWas able to get this fixed\nWouldn’t have spotted this without experimentation\n
\n
... And a game of foos\n
Attempting to move up our internal foos league\n
Main goal = solve problems. Often by writing code - - code is only part of the story.\n2 things we always need to consider are: \n1) Not the only person writing code. \n\n
Much here enables working with others\neg (standups, story cards, code reviews, pairing, automated testing, small projects, VCS...)\n2) Maintain and add features to a running system, with many global users. \n
This gives us many other things to consider than just making nice, functioning code. \nUnderstand and monitor code in prod and build good systems to get it there safely.\n\nThat’s all\nShowed you something of what it is like to be a Java developer, and the variety of activities and ideas that make life interesting.\n\n
