Some Advice to Recent College Grads

Taken from a Reddit post I recently wrote:

I've seen more than a few posts of "kids" having their real life experiences not match up to their dreams, particularly the recent Fortune 500 post which was unfortunately deleted. As a self designated "old man" I just wanted to throw out some advice and thoughts. This is primarily for those about to start or who just started.

1. You're probably going to get off to a slow start. Large organizations usually have a lot of business workflow (re: bureaucracy) around getting new employees set up, new accounts created, permissions to those accounts, etc, and the people responsible for getting you there have other, probably more pressing, things to do. The best place I ever worked, for a purpose I loved and with teammates I miss every day, it took a month to get going. It's hard to show initiative during this phase, it's usually mind-numbingly boring, and it makes you regret your decision. My recommendations during this time are - ask to read any business workflows/diagrams/whitepapers/disaster recovery/etc around your product, ask to attend any meetings related to the product even if unrelated to you writing code, and ask to pair program with someone. Hell, offer to be the Dunkin/Starbucks runner if you don't have UberEats near you. Do these things not just because they'll appreciate you, but because it'll keep you busy and hopefully learning. This is sort of universal, in fact Smarter Every Day (set to start around 3m20s) recently covered it in a semi-related fashion.

2. They probably don't follow every best practice your teachers taught you in college. 20 years now and I've never worked at a place big on unit tests or code documentation, CI/CD, etc.

   • Testing - a lot of places prefer integration tests to unit tests and/or have a QA staff sitting around which frankly the devs will just dump the testing on them. It doesn't make you friends with the QA staff but at a place where it's the 'norm' it is hard to break the cycle.

   • Code documentation - Code documentation is usually reserved for things that are out of the ordinary. Your code should be self documenting (assuming you're not programming assembly or a language with a very finite vocabulary). You'll probably only see documentation when someone has to explain why something "stupid" is being done (for an integration or equally stupid business process). I just checked my git commits for the last week and I've written exactly 10 lines of comments to explain a really convoluted HTTP POST packet authentication implementation by a third party.

   • CI/CD - believe or not, CI/CD is still "new". You've probably always done it, but the industry has not. If you need proof of that then I point you at Jenkins and their current internal strife over how to move forward because they've gone from "run Java unit tests" to "be responsible for someone's CI/CD" in the last fifteen years. Hopefully someone here has better GoogleFu than me but a few months ago an article ran, I believe it was a Jenkins blog post, about some big(?) changes coming for them to increase their CI/CD abilities because Jenkins primary use has changed. Anyway, I say this just so you don't hate the place for not having implemented it yet. Maybe you can be the person that gets them going?

3. They probably aren't running the latest technology. Kind of with CI/CD, but a bff of mine is the lead on a large project and recently hit a problem. Their product is programmed in the old ways of Javascript webpages (jQuery/jQueryUI) and their devs are used to it, familiar with it, and it works. But every new hire they have out of college has no idea what's going on because they've spent most of their education working with React or Angular. The old people are annoyed that the young people want to rip it all out, the young people are annoyed that all of this old stuff they have never seen before even exists. He is biting the bullet and has the young people updating them to Vue, but at a steep cost to productivity since only the new "kids" know how to work with it. This is a common scenario that will always exist in tech because new things are always coming out, so don't get ridiculous about it. In fact, get sympathetic about it because in 10-15 years you're going to be the "old people".

This has already gotten longer than I wanted so I'm gonna be quick about the last bits.

If you find yourself witnessing what you think is poor financial management, like "they're paying for me to do nothing after I just joined" or "they bought this equipment that's barely used!" it probably comes down to these two things:

1. It isn't noticed on the bottom line because the organization is so big so it isn't important to them.

2. Costs in companies/government organizations, after they reach a certain size, aren't handled well. People get assigned budgets and if they spend it all then they get it again the next year, if they don't then they get a smaller budget the next year and get punished if they exceed it. This often causes end of the year (end of the financial year is usually October) equipment purchases. It's bullshit and horrible, but it's almost universal. So if you want a bigger monitor or new laptop, ask your boss around the end of September early October. ;-)

If you find yourself wondering how a bad, or at least imperfect plan, made it to production, well General Patton said it best - A good plan violently executed now, is better than a perfect plan next week. Sometimes it's better to just get shit live so it can get used than it is to perfect it. One of my favorite coworkers was also my main adversary because he always sought the 100% solution. Honestly, he's probably smarter than anyone who's going to read this and certainly smarter than the guy typing this, and given enough time he could reach that. But when customers need it now and they're the ones ultimately paying your salary, then you release at 99%. Nobody pushes "fake it til you make it" like Silicon Valley.

More than any generation before you you have been fed a lot of instantly gratifying experiences, but unfortunately, starting a job is usually not instantly gratifying.