Not the typical Hacker News reader, but might be interesting for some. I used to work (I am a graduate student now) at the Poverty Action Lab (J-PAL, http://www.povertyactionlab.org) in Latin America. It is a research center that fights poverty by building evidence on which public policies and social programs work (and which do not work).
In my last role as "Policy Manager" it is difficult to define a typical day, but it was mostly managing people, projects, reading papers to pick up messages for policymakers, writing policy memos, some traveling, some consulting for governments, making presentations, and managing upwards.
i really like this question because i'm not too old to remember my first civil engineering job, and my complete lack of preparation for working in a corporate environment with meetings and lots of boring boring work. so:
at a large company i am a senior data scientist supporting a business org. i have a lot of experience at this point in business management, and i'm valued for my combination of business competence and sql coding. i've developed a level of trust with my management org, and i've attained the highest non-manager level available. i am not at immediate risk of being dumped, so that stress is gone although with the next management rotation things can change quickly.
i show up at work around 10ish.
if i don't open email i can be productive for an hour or so before someone bothers me with an irrelevant line of inquiry.
usually i play 2 to 3 games of ping pong before the afternoon rush on the table on our floor.
i always fit in an hour of study during the day, these days i'm trying to get past the grievous irritations of tableau or learning new joys of julialang.
i was studying statistics, but i got an intern to manage so now my time is crimped.
by the afternoon (after an hour lunch - burger and beer) i am focused on my self-managed issues panel, and try to knock out some sprint items. these are typically datawarehouse extracts with some analysis and tables of sort/filter variety.
quitting time always comes too fast, but with a newborn at home i dont stay late any more. no one seems to notice or care, as long as i am able to grind when the chips are down (and they are at a loss to explain sone financial results in the monthly P&L review).
Probably those with non-average "average days" are more likely to respond so I'll balance it out by stating the useless and the obvious:
Average days are average. Average is boring.
My average day:
* 9 AM arrive
* 10 AM standup
* code until lunch
* code all afternoon
* 6 PM leave
Corporate system pressures you to be average, but your boredom will pressure you otherwise. Always find new things to work on, meet new people, don't burn any bridges, stay sharp.
Depends on what sharp means to somebody as well as what their job entails. I'm unfortunately doing SSIS/ETL work which I don't want to do. I stay sharp with the technologies I want to use by doing work with them outside of work.
Im a junior salesman at a mid level paper company. My day-to-day is pretty standard. Ill meet a few clients maybe close a sale or two. I do have to stay vigilant though because some of my coworkers are very unprofessional and like to waste time on pranks. Fortunately though, my boss is a great guy, and my personal mentor. Ever since he named me assistant to the regional manager, our branch has dominated the northeastern regional paper market.
All in all, it not a bad gig. I have a 50 acre beat farm which I run together with my cousin, so that keeps me busy and entertained.
I am a senior cloud engineer at a midsized software company. We provide a product that customers can choose to host internally or use via our cloud service.
A typical day for me varies greatly depending on if any customers are having issues. If so, I work to help solve the problems and get things working again. Otherwise, my time is spent maintaining our cloud systems, performing maintenance activities, and working on projects to improve our internal monitoring and automation tools across our cloud infrastructure and customer portal site.
My email inbox can be around 1000 messages any given morning that I have to go through before even looking at our internal support queue system and any items flagged in our monitoring system that need attention.
It can be pretty busy, so at least once a week I miss eating lunch due to workload, meetings, or customer issues. But overall not bad compared to other roles I have heard about.
Im a vp of growth at a enterprise api startup. day-to-day usually starts with an early call between 7-8 with an int'l client or prospect. work from the office in SF 2-3 times per week, in SV once every other week or so, work from home the rest of the time. Get into the office between 9-930. catchup on emails, 2-3 calls/demos before lunch. afternoon is some team chats, a couple more calls/demos and call it a day round 6. at night is when the fun begins: working on side projects ;)
Not sure whether I should call it a work day: I get paid and it's exhausting, but it's also school. An extended job training, perhaps.
My average day:
4:15 -- Get up, make breakfast, pack lunch, drive to work
5:00 -- Study for two hours at school before classes begin
7:00 -- Class for two hours
9:00 -- Study for one hour
10:00 - Class for two hours
12:00 - lunch hour: half hour eat, half hour study
1:00 -- Class for two hours
3:00 -- Study for two hours
5:00 -- Go out to my car, read on my phone or work on my computer on my own projects for 30-60 minutes until traffic improves somewhat.
Sometimes I leave by 4; more often I'll keep studying until 6.
It's slightly similar to college, but the people are all pretty much on the same page (and diligent), and I'm constantly slammed with so much material that I have to be less mechanical about my studying (triage rather than just learning everything). At least it's interesting stuff. And it's nice to be 'done for the day' when I leave, which obviously isn't too common in college.
A wonderful opportunity to collaborate with a large variety of people doing a large amount of varied work.
I'm not strictly tech, more banking-tech-BPO cross-over.
Best moments, at the start: Playing with data and discovering fascinating stuff. Best moments now, 15 years later: mentoring and helping others grow, and in the process, doing so myself.
10:30 or more likely, come in late to the office :D
10:30-11:00 free breakfast with a variety of drinks and patisserie. sync with other people
11:00-12:00 check emails & messages & chat & more sync
12:00-13:00 fix or improve whatever just broke, if anything. take a preemptive look at my hundreds of services. find stuff to do that is not too long because there is lunch soon.
13:00-14:00 free catered lunch
14:00-18:30 get stuff done... but nothing too major because it's peak traffic, hard changes in production should be in the morning.
18:30 leave early
18:30-19:xx or most likely, start reading HN and forget to leave early.
8:30 AM - Rush into work to get on a screen-share with some customer that is based out of India or Saudi Arabia or Australia, trying to chase the time difference.
8:40 AM - Customer never joined conference call, grumble about the normal morning pre-work routine that's been disrupted for no reason.
9:00 AM - Make the mistake of checking email. Realize some customer has had a problem with our software. Details are sketchy at best. Compose an email asking for more information, log files, screenshots, a coherent description of the issue, anything.
10:00 AM - Boss rolls into work, starts checking his email. Torrent of emails sent out about status of half a dozen disparate projects and evaluations. Seizes upon possible customer issue, demands immediate all-hands meeting to discuss the problem, even though the customer has yet to provide any information.
10:30 AM - Pointless standup meeting.
11:00 AM - Customer with the problem proves themselves once more incapable of following directions, sends completely unrelated set of log files and screenshots. Still no description of what the problem was. Query for the correct information.
12:00 - Flee for lunch.
1:00 - Post-lunch coma.
1:30 - Try to actually knock out some tickets and get something done.
1:35 - Customer finally sends decent bug report with information that can be analyzed. Except they are running an ancient version and refuse to update. Pull down old version of software to cross-check logging information and reproduce issue. Realize issue was fixed a year and three point releases ago. Tell customer to upgrade, which will take three to six weeks to percolate through their lab, staging and finally production environments, amassing copious amounts of red tape along the way and requiring sign-off by no fewer than seven different groups. Prepare temporary work-around to quiet down the issue in the meantime. Get ambushed with three other issues that have been occurring for weeks but were never brought to attention.
4:00 - Free once more to try to squeak out some forward progress for the day. Get pulled into hall-way conversation about some terrible idea for a feature that somebody who was given a demo of the product idly asked for, and sales interpreted as a show-stopping, must-have, stop-the-sale, not-going-to-make-my-quota blocker.
4:55 - Fuggit, it's time to go home.
Not all days are like this, but when you get into a stretch of them, whoo boy.
Where I work, we definitely get too many customer recommendations that are treated as show-stopping by someone in our business side. Often the customer will only vaguely remember making the recommendation a few months later, and it turned out to not be that important. Gee, thanks business people, for wasting 3 weeks of software engineer's time and lots of the owner's money!
Well, I generally come in at least fifteen minutes late. I use the side door, that way Lumbergh can't see me. Uh, and after that, I just sorta space out for about an hour.
I do that for probably another hour after lunch too. I'd probably, say, in a given week, I probably do about fifteen minutes of real, actual work.
I've been out of school for about five years, and had several different jobs. Think the most surprising thing was that as a student I have a strong belief in what I wanted and work. I found this belief to be incorrect.
At my first job I was hired on to a team that was in my Focus topics. The majority of my days were scrum Style. I was the first developer on this team, and it took about four months for the company to staff everybody correctly. This created a moving Target for our release goals. I was working in a very large code base, on an isolated feature . We still needed several developers in order to complete our task . The majority of conversations that our team had ,including during our scrum meetings , was on addressing these moving targets. We did all of our scrum and project planning using the traditional sticky note meetings. Although I believe I learned a lot of this company, and none of it had to do with the domain I thought I would.
My second job out of school, the projects were much smaller. I had a principal investigator who would Drive the project and act as a resource to me as I needed. The principal investigator was in charge of highly technical content, the team leader was in charge of reporting and optimizing on our workflows/progress. Every small team in the company used a different technology in order to report to their team lead. I used Basecamp for one team, and jira for another . For any software I felt we needed to complete our task, I was in charge of making the engineering and Design decisions. Everybody's schedule at the company was open access, and I could add myself to any meeting, or create a new one to gain appropriate advice.
My third job was remote contract work. I worked about 20 hours a week. Here, my tasks started by moving their technology stack to the cloud, in order to better facilitate remote work for everybody at the company. I would also hold regular conference video calls with Junior developers to grow them in several programming languages, and ides, and walk through code reviews / debug sessions . When working with mid to senior-level Developers, there was a very similar workflow to my second employer. When working with Junior developers, or with the business management side of the company, I was in charge of translating our discussions into tickets and appropriately handling them.
During this time, I also began volunteering for a project where I drove around the United States Gathering raw data by photographing Street lamps. Here I wrote a support software, as the primary developer. I moved towards using as much free and simple software as possible period off and making decisions based on whether or not a novice contributor would be able to extend my work at any given time. I would also hold sessions for scientists in our group, without prior programming background, to grow their knowledge in the domain.
At my fourth job out of school, I served as a ticket processing machine. I was at a very large company, and I would show up every day, check a ticket list, and select one to work on. This was a company where human interaction did not contribute to business success. Once a week we would talk about what our blockers were. The rest of the time we would clock an 8 hour day following a ticket. Much of my work here, was in replicating data storage environments in order to address bugs.
While working here, in the evenings , I taught at a boot camp. This meant that most of my weekend was spent developing curriculum.
27 comments
[ 3.6 ms ] story [ 59.0 ms ] threadIn my last role as "Policy Manager" it is difficult to define a typical day, but it was mostly managing people, projects, reading papers to pick up messages for policymakers, writing policy memos, some traveling, some consulting for governments, making presentations, and managing upwards.
If you are interested take a look at a new Micromasters they launched along with MIT on Data, Economics and Development: https://micromasters.mit.edu/dedp/?utm_source=odl&utm_campai....
at a large company i am a senior data scientist supporting a business org. i have a lot of experience at this point in business management, and i'm valued for my combination of business competence and sql coding. i've developed a level of trust with my management org, and i've attained the highest non-manager level available. i am not at immediate risk of being dumped, so that stress is gone although with the next management rotation things can change quickly.
i show up at work around 10ish. if i don't open email i can be productive for an hour or so before someone bothers me with an irrelevant line of inquiry. usually i play 2 to 3 games of ping pong before the afternoon rush on the table on our floor. i always fit in an hour of study during the day, these days i'm trying to get past the grievous irritations of tableau or learning new joys of julialang. i was studying statistics, but i got an intern to manage so now my time is crimped. by the afternoon (after an hour lunch - burger and beer) i am focused on my self-managed issues panel, and try to knock out some sprint items. these are typically datawarehouse extracts with some analysis and tables of sort/filter variety. quitting time always comes too fast, but with a newborn at home i dont stay late any more. no one seems to notice or care, as long as i am able to grind when the chips are down (and they are at a loss to explain sone financial results in the monthly P&L review).
basically, on average its pretty great.
Average days are average. Average is boring.
My average day: * 9 AM arrive * 10 AM standup * code until lunch * code all afternoon * 6 PM leave
Corporate system pressures you to be average, but your boredom will pressure you otherwise. Always find new things to work on, meet new people, don't burn any bridges, stay sharp.
A typical day for me varies greatly depending on if any customers are having issues. If so, I work to help solve the problems and get things working again. Otherwise, my time is spent maintaining our cloud systems, performing maintenance activities, and working on projects to improve our internal monitoring and automation tools across our cloud infrastructure and customer portal site.
My email inbox can be around 1000 messages any given morning that I have to go through before even looking at our internal support queue system and any items flagged in our monitoring system that need attention.
It can be pretty busy, so at least once a week I miss eating lunch due to workload, meetings, or customer issues. But overall not bad compared to other roles I have heard about.
My average day: 4:15 -- Get up, make breakfast, pack lunch, drive to work
5:00 -- Study for two hours at school before classes begin
7:00 -- Class for two hours
9:00 -- Study for one hour
10:00 - Class for two hours
12:00 - lunch hour: half hour eat, half hour study
1:00 -- Class for two hours
3:00 -- Study for two hours
5:00 -- Go out to my car, read on my phone or work on my computer on my own projects for 30-60 minutes until traffic improves somewhat.
Sometimes I leave by 4; more often I'll keep studying until 6.
It's slightly similar to college, but the people are all pretty much on the same page (and diligent), and I'm constantly slammed with so much material that I have to be less mechanical about my studying (triage rather than just learning everything). At least it's interesting stuff. And it's nice to be 'done for the day' when I leave, which obviously isn't too common in college.
I'm not strictly tech, more banking-tech-BPO cross-over.
Best moments, at the start: Playing with data and discovering fascinating stuff. Best moments now, 15 years later: mentoring and helping others grow, and in the process, doing so myself.
10:30 or more likely, come in late to the office :D
10:30-11:00 free breakfast with a variety of drinks and patisserie. sync with other people
11:00-12:00 check emails & messages & chat & more sync
12:00-13:00 fix or improve whatever just broke, if anything. take a preemptive look at my hundreds of services. find stuff to do that is not too long because there is lunch soon.
13:00-14:00 free catered lunch
14:00-18:30 get stuff done... but nothing too major because it's peak traffic, hard changes in production should be in the morning.
18:30 leave early
18:30-19:xx or most likely, start reading HN and forget to leave early.
8:40 AM - Customer never joined conference call, grumble about the normal morning pre-work routine that's been disrupted for no reason.
9:00 AM - Make the mistake of checking email. Realize some customer has had a problem with our software. Details are sketchy at best. Compose an email asking for more information, log files, screenshots, a coherent description of the issue, anything.
10:00 AM - Boss rolls into work, starts checking his email. Torrent of emails sent out about status of half a dozen disparate projects and evaluations. Seizes upon possible customer issue, demands immediate all-hands meeting to discuss the problem, even though the customer has yet to provide any information.
10:30 AM - Pointless standup meeting.
11:00 AM - Customer with the problem proves themselves once more incapable of following directions, sends completely unrelated set of log files and screenshots. Still no description of what the problem was. Query for the correct information.
12:00 - Flee for lunch.
1:00 - Post-lunch coma.
1:30 - Try to actually knock out some tickets and get something done.
1:35 - Customer finally sends decent bug report with information that can be analyzed. Except they are running an ancient version and refuse to update. Pull down old version of software to cross-check logging information and reproduce issue. Realize issue was fixed a year and three point releases ago. Tell customer to upgrade, which will take three to six weeks to percolate through their lab, staging and finally production environments, amassing copious amounts of red tape along the way and requiring sign-off by no fewer than seven different groups. Prepare temporary work-around to quiet down the issue in the meantime. Get ambushed with three other issues that have been occurring for weeks but were never brought to attention.
4:00 - Free once more to try to squeak out some forward progress for the day. Get pulled into hall-way conversation about some terrible idea for a feature that somebody who was given a demo of the product idly asked for, and sales interpreted as a show-stopping, must-have, stop-the-sale, not-going-to-make-my-quota blocker.
4:55 - Fuggit, it's time to go home.
Not all days are like this, but when you get into a stretch of them, whoo boy.
09:10 Stand-up meeting
10:00 Agile meeting with all departments
11:30 Personal status meeting
12:00 Lunch break
12:30 Browse HN
13:00 Coding / code reviews
14:00 Priority meeting, turns out what was planned at 11:30 is no longer valid
14:30 Coding / code reviews
17:00 Another status meeting meeting
18:00 Leave
Sometimes I may have more status meetings (avg=3) but you get the picture.
I don't get much done tbh.
8 am review all newly admitted patients and patients who came for investigations
9 am ward round with the consultant
10 am write discharge cards of all the patients that the consultant discharged
12 pm lunch
1 pm review all the new admissions that came during this time
2 pm review all the new complaints of patients who are at the ward
3 pm write and discharge patients who are supposed to be discharged by 5
4 pm go home have a wash
6 pm come back and review all patients at the ward
7 pm evening ward round with consultant
8 pm go home if there is no emergency or patients that need my attention
Repeat
09:00 Status meeting (~2 times a week)
09:30 Coffee break, chatting with colleagues
10:00 stare at screen, press keys on keyboard
12:00 lunch
13:00 stare at screen, press keys on keyboard
15:30-19:30 (depending on day/mood) head home.
I do that for probably another hour after lunch too. I'd probably, say, in a given week, I probably do about fifteen minutes of real, actual work.
At my first job I was hired on to a team that was in my Focus topics. The majority of my days were scrum Style. I was the first developer on this team, and it took about four months for the company to staff everybody correctly. This created a moving Target for our release goals. I was working in a very large code base, on an isolated feature . We still needed several developers in order to complete our task . The majority of conversations that our team had ,including during our scrum meetings , was on addressing these moving targets. We did all of our scrum and project planning using the traditional sticky note meetings. Although I believe I learned a lot of this company, and none of it had to do with the domain I thought I would.
My second job out of school, the projects were much smaller. I had a principal investigator who would Drive the project and act as a resource to me as I needed. The principal investigator was in charge of highly technical content, the team leader was in charge of reporting and optimizing on our workflows/progress. Every small team in the company used a different technology in order to report to their team lead. I used Basecamp for one team, and jira for another . For any software I felt we needed to complete our task, I was in charge of making the engineering and Design decisions. Everybody's schedule at the company was open access, and I could add myself to any meeting, or create a new one to gain appropriate advice.
My third job was remote contract work. I worked about 20 hours a week. Here, my tasks started by moving their technology stack to the cloud, in order to better facilitate remote work for everybody at the company. I would also hold regular conference video calls with Junior developers to grow them in several programming languages, and ides, and walk through code reviews / debug sessions . When working with mid to senior-level Developers, there was a very similar workflow to my second employer. When working with Junior developers, or with the business management side of the company, I was in charge of translating our discussions into tickets and appropriately handling them.
During this time, I also began volunteering for a project where I drove around the United States Gathering raw data by photographing Street lamps. Here I wrote a support software, as the primary developer. I moved towards using as much free and simple software as possible period off and making decisions based on whether or not a novice contributor would be able to extend my work at any given time. I would also hold sessions for scientists in our group, without prior programming background, to grow their knowledge in the domain.
At my fourth job out of school, I served as a ticket processing machine. I was at a very large company, and I would show up every day, check a ticket list, and select one to work on. This was a company where human interaction did not contribute to business success. Once a week we would talk about what our blockers were. The rest of the time we would clock an 8 hour day following a ticket. Much of my work here, was in replicating data storage environments in order to address bugs.
While working here, in the evenings , I taught at a boot camp. This meant that most of my weekend was spent developing curriculum.
- coding 5hrs
- emails 1hr
- discussions, huddles, meetings 1hr
- lunch, coffee , walking around 1hr
- reading, browsing, hacker news 1hr