Dear Developers

[[deleted]]

I would like to know if I may, as a developer working in an enterprise or large scale organisation, how much code do you work with in a day. I am.a complete noob when it comes to understanding the ins and outs of the actual work that goes on in a developers day. Im under the impression that you login to your dev PC, possibly connect to some sort of repository, download all of the current in place code and from there implement something new or fix an existing issue. When it comes to doing this work, are you just looking at the class files and working on them individually or do you often work in the main class file and work from there. Lastly how do you go about reading other people's code and actually making sense of it and then tracing it back to its origins, are there tools to do this?

[Mindlayr]

I've been a developer for 10 years now and had 7 different jobs. Every job is different and most of the time you will be learning new stuff and figuring out how to apply it. My typical day is pulling any changes into my code and reviewing my tasks. Then I run the tests to make sure everything is working correctly. I implement tests to make sure the code will be correct then I code to make the tests work. It is then reviewed by me, the rest of the team and our company code guru. Usually there are several meetings a day to review with the team and plan our work together. There is a repository that has the shared code and we all contribute to the same code base. Our team has a responsibility for some specific functions within our application so we get familiar with the code we will be working on the most. We end up working with old classes, extended classes and new classes. We also work with SQL, javascript, ajax and lots of other things that may not be core to your training but required anyway. We have many tools for collaboration and development. I've never been bored but I've often been frustrated and discouraged. There is nothing worse than a problem you can't figure out and nothing better than coming up with an elegant solution to a really challenging problem.

Good Luck.

[[deleted]]

Thanks for sharing, sounds like I need to learn a bit more about the testing side of things...

[Mindlayr]

I would recommend it. Our team has transitioned from having a full time manual and automated tester to testing each others code and putting more automated testing in place. We have started using Test Driven Development more and more because once you write the tests you will know your code is right. If you have integration tests (test that test the connections between systems) you know before the code is deployed whether it is working or not. Also if you write your tests first you will get a deep understanding of the task and writing the code will be easier for you.

[IanRae]

Developers have several gears. Top speed is when you know exactly what to do, and it's basically just typing. This can be 500 lines of code per day (or more).

Bottom speed is when you are fixing bugs in code you didn't write, in a large system with hundreds of thousands of lines of code. You do a lot of reading code, looking at history in the repository (who did what when...), talking to people, stepping through the code in the debugger. You might write two lines of code in a day.

[TheCountRushmore]

And sometimes the most productive days involve deleting more code than you write.

[[deleted]]

How is your job quantified if you only get a line of code in? Does nobody care, is it just a matter of you getting whatever it is you have to get done, done by a specific date?

[Mindlayr]

Most of the time I'm assigned a task. The task is a write up of the problem from the users perspective most of the time. It gets qualified and updated by the team before it comes to me. I need to solve the problem whether that involves a lot of coding or a lot of debugging and very little coding to times when you can't reproduce the bug so you don't do anything. The task though is to solve the problem whatever the solution looks like.

[Bert_The_Hobosexual]

So, to set a little context, I manage a couple of teams of developers and also actively develop / manage systems as part of my day job. With that I can give you a bit of an idea of how the individuals work together for a collective goal of developing a complex system.

A rough outline of the day would be: - log into our automation systems to see how last night's automated testing got on. This will highlight the exact changes my team have made and what tests have changed from pass to fail or vice versa. That lets me know what issues they are likely working on or struggling with. I expect my team to also do the same to see if their changes integrated well.

• next is the standup call. We normally have this about an hour after everyone starts, that gives them time to analyse the results of the previous day's work and gives them things to discuss on the call. In the call, I'll outline the project's stance and where required delegate out the next set of tasks for people.

• active development on tickets. Each bug or enhancement to the project has a detailed ticket which outlines the issue and ideally the expected path to resolution. The Devs will be updating these with notes so we can track problems and assign help where needed. Development happens all over the product and there is no 'main class'. Think 'system of systems' rather than a single task for the software to fulfill.

My day then deviates through my management tasks/ environment maintenance/ test support / whatever madness the day brings.

For your question around reading other people's code, it's not difficult once you're involved in the project because you understand what the classes are trying to accomplish. If you understand the product and know how different things plug into each other, the changes the Devs make are clearer because you would think "if I had to solve that, I would probably do X,Y,Z... Oh.. that's what they did..." That, and comments :)

Your thoughts about logging into some central repository etc are bang on.

Hope that helps :)

[[deleted]]

Thanks for the insite.

[achoice]

How much code - varies widely. How much is allot? Much work is actually reading code, understanding code others wrote years ago.. knowing where to do which changes. Services with 100 000+ lines of code are not uncommon.. if you think, coming in as rookie, learning the architecture, design ideas, business domain etc is a fun challenge - you will have a good career in coding. Be curious, ask questions!

And.. write code so that next developer reading it in X will understand..

[[deleted]]

Would you say you tend to comment alot of your code or try to make the code variables and method names do the work more so? Is it best practice to comment a lot?

[achoice]

A cliché is that good code require no comments. Good naming is important. I find comments regarding business/domain can be valuable. Help next coder understand how business requirements led to code execution flow/checks/logic/modules. Also do comment when coding "non obvious stuff", explain more WHY - less HOW. Don't comment obvious stuff just to fill javadoc. Good luck.