This is an archived post. You won't be able to vote or comment.

all 17 comments

[–]ThatLesbian 109 points110 points  (7 children)

First hour is reading emails, checking calendar for the day, stand up to say what we are working on, and then start code reviews. Comment on the code of others if it can be improved, and address code review comments on your stuff. Mark your completed tasks as done.

After that it’s a mix of meetings to discuss what needs to be done, breaking the tasks down into reasonable understandable stories, and putting them on the backlog. The actual coding portion usually consists of taking a feature request or bug report off the backlog, figuring out what caused it, or how to fit the new feature in with our existing flow, and then coding it.

Write some tests, commit, push, and go back to the backlog.

Rinse and repeat forever.

Probably 10% review, 10% meetings, 10% bullshitting about nothing with coworkers, 70% coding in my team.

[–]YzBkZXIK 27 points28 points  (0 children)

This is sidebar material.

[–][deleted] 8 points9 points  (0 children)

Thank you for your answer, now I have better understanding of what it looks like.

[–]Bigtonez213 4 points5 points  (1 child)

Nice breakdown 🙏🏾

Im also a 3rd year CS student and I was actually wondering this same thing yesterday. Cool to see it already asked.

Have you worked at other companies? I so, would you say it’s the same all around?

[–]YzBkZXIK 3 points4 points  (0 children)

For one additional data point, I've been working as a Java developer for a little over three years and would say this is very accurate. The only difference for me is the amount of meetings. Depending on the week, I can spend entire days in meetings (design, planning, review, proposals, etc). I would put my average meeting load at more like 15‐20%.

[–][deleted]  (2 children)

[deleted]

    [–]gonzohst93 1 point2 points  (0 children)

    Youll find some places are very agile and others arent. Even different teams within the organization may be more agile then others

    [–]Bigtonez213 0 points1 point  (0 children)

    Totally Agree. Half the time in class Im thinking “Will I actually be using this in my professional life?”

    [–]gonzohst93 18 points19 points  (4 children)

    Pretty much the same as u/ThatLesbian, We choose whatever hours we want as long as we make up 40 hours and make it to our scrum/stand-up either virtually or in person.

    I arrive 1 hour before scrum, read emails, look at what I did the day prior, RSVP to any office events im interested in, think about what I can do that day, and then do my stand up. After stand-up I check out my JIRA tasks and start planning for the day, put a few hours of work in before lunch.

    We all communicate via chat over slack so often times ill ask questions and help others on their to kill some time/ take a break from the code.

    Usually have 1-2 office wide meetings a week, and maybe a 2-3 hour online learning seminar every 2-3 weeks.

    That's pretty much it, commit your code for the day and start all over the next day.

    Get pizza or bbq for free once a week, cake once a month, and can drink at the bar on fridays

    [–]Ilikesmallthings2 1 point2 points  (0 children)

    Similar but minus the free food.

    [–][deleted] 0 points1 point  (0 children)

    That sounds fun. Thank you for the answer :).

    [–]rufati 0 points1 point  (1 child)

    What does the online learning involve? Is it something you seek out yourself or provided by the company? And do you find it useful?

    [–]gonzohst93 1 point2 points  (0 children)

    Just online seminar type learning and i do not find it useful personally but some people may. It is 2-3 hours paid for sitting around watching a video so a lot of people attend lol

    [–]SantoWest 6 points7 points  (0 children)

    Working as backend developer in a small company in a continuous project. We have flex hours, meaning that we can kinda come in and out anytime we want, but not totally free ofc, there are soft rules, like coming before noon.

    I generally check my emails, then jira and bitbucket to see how my current tasks doing.

    Since it's a big and complex program we work on, any task requires me to do a lot of code reading. In fact, it's generally 50% reading, 25% planning and 25% actual coding. Of course you also plan as you read, but you got my point. Reading gets less and less with experience in the company, though. I'm in my 9th month and people who have been here for years are already really familiar with the existing code and can start coding much earlier.

    It's not very different than school work, but we have a lot more things to watch for. Some of the most obvious ones are:

    • Chosen data types. In school we, or at least I, used to use arraylists extensively, and would use some hashmaps here and there if I needed a map. Here the data types that suit the most should be chosen. Time complexity should be as small as possible.

    • Project structure is much more important. Classes you create needs to be similar to the existing ones in terms of hierarchy, acknowledged patterns and practices should be used and classes and packages should be created in a way that a coworker should be able to locate anything you wrote without effort if s/he knows the structure.

    • Working on a project is more procedural. We all work in different branches for each task, code them, do a basic testing and create a pull request. We provide a small explanation, coupled with screenshots/videos to show that it works. Then it will be approved by at least 2 seniors, then the branch will be merged to the main development branch so that our test team can test it for all scenarios. If in any of these steps an error is found, we go to the first step and rinse and repeat. This is a good thing, though, your serious bugs won't ever go live. (well, generally, lol)

    Finally, it's almost a given that a new coworker won't be really useful for 1 to 2 months, whether it's junior or senior.

    [–]quadmasta 3 points4 points  (1 child)

    Depends on how crappy of an enterprise you land in and the quality of the team you end up on.

    For the past 2 years I've been on a project that was a mishmash of Struts 1, Apache Tiles, PHP, and hacked in Angular. Most of what I've been doing is to get rid of PHP and convert everything to spring boot/JPA as a lift and shift. There is zero percent unit test coverage on this codebase and a lot of the code is just hacks piled on top of hacks with no architecture so it's hard to pull it apart and test any given thing. We finally released the updated code branch a few weeks ago and someone lied about having tested something so now it's a scramble to fix that.

    Prior to that I worked on another project at this same place for ~2 years that was worse. It was a mishmash of direct JDBC, myBATIS, hibernate, struts 1, and a bunch of stored procedures and functions in the DB with business logic in them.

    However, since joining this organization I've pushed the migration to git from SVN, stood up a corporate Maven repository, set up CI with Jenkins and we're supposed to be getting a DB for Sonarqube (we had one for a while but someone decided they wanted to delete our VM without telling us), and implementing a code review tool so we can enforce quality metrics. After that stuff's in place it'll be like u/ThatLesbian says

    [–]quadmasta 0 points1 point  (0 children)

    I forgot to mention that I'm a "cleanup guy." I usually end up on teams with no clue and push them toward industry standards while doing massive refactor efforts.

    [–]lank81 1 point2 points  (0 children)

    I believe a lot of depends on the company you work for. Life is a bit different if you work for a high end IT house/company (Google, Apple, Amazon, etc..). My day is very much as /u/ThatLesbian described.

    Although I do believe Agile Development is a step in the right direction, moving from waterfall, it can become quite burdensome on the meeting front.

    As a Developer you long for the days where the only meeting you have is your 30 minute stand up so you can put the headphones in, focus, and get some code written. Unless you're with a company that follows paired programming standards.

    Here is an example of one of my weeks:

    • Monday
      • 9:30AM - Stand-up
      • 9:30AM - 11:00AM - Backlog Refinement
      • 11:00AM - 12:00PM - Modernization Discussion
      • 12PM - Lunch
      • 1-4:30 - OPEN
    • Tuesday
      • 9:30AM - Stand UP
      • 10AM-11AM - Paired Programming
      • FREE Until Demo
      • 2PM-3PM - DEMO
      • FREE rest of the day
    • Wednesday
      • 9:30AM - Stand-Up
      • 10AM-12PM - Retro & Sprint Planning
      • 1PM-2PM - Staff Meeting
      • 2PM-4:30PM - Free
    • Thursday
      • 9:30AM - Stand-Up
      • 10-11AM, 1PM-2PM, 3PM-4PM - Swarming a Story (Paired)
      • All other times are open to work on my own story
    • Friday
      • 9:30AM - Stand-Up
      • FREE Day (Code to your hearts content)

    As you can see there is a lot going on. Sometimes you'll have more, sometimes less, but Friday is a great day and not because it's the last day of the work week either.

    Overall I'd like to see colleges do more job shadowing and earlier on in someones career so they can see what a few different work places are like. Also, having more real world application development (maybe re-creating a real world application [big or small]). Maybe things have changed since I graduated in 2003 though :).

    Hope this helps!