College is designed to teach you a bunch of stuff, but one of the biggest lessons comes from “finals week”. This part of the semester also includes the week before finals, when nearly every goshdarn class seems to have a big project due (like they are the only class that you are taking). The double-whammy of big project + cramming & final exams, is a pinnacle. These two weeks are grueling and really test your mettle. You work your butt-off and spend seemingly endless amounts of time, studying and obsessing about your classes, all so you can earn the best grade possible.
The good news is that this process teaches you a very valuable skill. In your real job (and career, overall) you will periodically experience intense periods, just like finals week. Hopefully, it doesn’t happen more than 2-3 times per year.
In college, after finals, there is always a week of downtime. Students are supposed to use this time to catch up on everything that was neglected during the previous two weeks, and it is a chance to re-charge. It is also a period for reflection on how the previous semester went, and to contemplate what could be done next semester to improve things. I suppose there is even some time to celebrate your accomplishments and share the experience with your colleagues.
In your career (after college), you don’t usually get down-time like you did in college. It is the job of management to make sure that your workload does not consist of peaks and valleys, like you had in college. Those are not good for people and it can impact morale. However, if you are a programmer, this is naturally going to happen anyway, because it is part of the lifecycle of some software development processes (methodologies).
If you ever get some downtime, you DO NOT want to treat them the same way that you did in college.
Things to not do: (aka “Bad”)
Sleeping-in, partying, showing-up late, leaving early – Don’t even think about it. When there is down-time at work, management will be watching you closer than ever. There is a saying “idle hands are the devil’s workshop”. This is a test to see who is responsible and who is unable to manage themselves and behave consistently like an adult. You will not be warned about this. If you fail this test, you will be blind-sided weeks or months later. For some strange reason, all of the good work that you have done won’t seem to matter. You will be passed-over without any explanation. If this has ever happened to you, then please commit this warning to memory: Don’t ever think that nobody is looking. You are always being evaluated. Always. These are the moments where you will stand-out in a good or bad way.
Things to do: (aka “Good”)
Tech debt resolution – “You got time to lean, you got time to clean.” We all know that every dev project will contain some technical debt. Now is the time to assess it and catalog it. Make a wish list and prioritize it. Time is going to fly-by, so don’t put it off, and don’t be informal about it. Get management involved so they understand, or they might mistakenly think that this is some kind of boondoggle, or maybe it’s just “for the cool points” or something. Take it seriously, and help them take it seriously too.
Brainstorming – Now that the project is being used by real people, folks are going to become more-aware of what works and what is just awkward or downright frustrating. Start seeking feedback and start developing a list of suggested improvements.
Log monitoring – You are not a hack, so your system has some tracing and logging mechanisms. If anything goes wrong, you need to keep your nose in those logs so you know it before anyone else does. Watch PerfMon like a hawk. Find the next bottle-neck or two and be ready to fix any flaws promptly.
Process improvement – In every project there will be some good times and some bad. Now is the time to assess that while it is all fresh in your minds. Write it down and contemplate it. Just like the lull between semesters, you can use this time to figure out how to begin and execute the next project or phase better than the previous. Find root-causes, propose process changes, research new technologies and toolsets that could improve your next project (or phase/sprint).
Utility / internal / support apps – Once you start supporting your app, you start realizing that it would be easier if your app had better logging, reporting, more-granular tracing, better info, etc. It can be pretty satisfying to write an app for yourself (in a day or two) that makes your (or your whole team’s) job simpler.
Learning / self-improvement – Be careful about this one. Most managers will expect that you are already doing this at home, “on your time”. So if you are doing your homework at work, you are one-step-short-of doing nothing, or slacking, etc. It might seem like it is better than nothing, but there are probably things that you could be doing to bring the “wow” instead of just not-sleeping at your desk.
There are more things, but I think you get the picture. This is what leet looks like.