There are a lot of things I've learned in the two short years I've been out of college and out in the workplace. Here's a non-comprehensive list: Be willing to scrap days of work and start over...
Exemplary
There are a lot of things I've learned in the two short years I've been out of college and out in the workplace. Here's a non-comprehensive list:
Be willing to scrap days of work and start over fresh. You're going to run into problems where your initial approach turns out to be complete shit. That approach is a mistake. Don't cling to a mistake just because you spent a lot of time making it. Throw it away and start over. You'll thank yourself months down the road when you inevitably have to come back to it and don't have to face that monstrosity you rightly tossed into the incinerator.
Never, ever, ever run direct database queries on production without a damned good reason and extensive review and validation that your query isn't going to royally fuck things up. Better yet, write up a script or some other tool to help bake safety into the process. I've had a few close calls with this, luckily catching myself before the stupid could manifest in the form of data loss. Just save yourself the trouble of possibly having to go up to your boss to say "production is down because I destroyed customer data". Seriously.
Get used to the concept of technical debt. Any project of sufficient size and age will become more and more difficult to make changes to without either screwing up some other part of the system or needing to untangle a mess of code to figure out which parts you need to change. Learn to watch out for things that "feel" wrong. That's typically a sign of a "code smell", which is a large part of technical debt.
Learn to balance productivity in the form of implementing features, and productivity in the form of paying down technical debt. Both are important. Too little focus on paying down technical debt will cause your feature development to grind to a halt, and too much focus on paying down technical debt will likewise cause your feature development to grind to a halt. Make improvements as needed, accept that things aren't going to be perfect, and resume feature development as soon as the major development bottleneck has been eliminated.
Learn to love automated testing. For a brand new project, tests will probably only add an additional bottleneck that will prevent you from meeting critical deadlines, but for projects that have grown sufficiently, they will help you make changes quickly and safely by allowing you to validate that nothing was broken. I can't overstate the value in being able to run a script like ./run_tests.sh and have a test suite report back to you which of your test cases are failing and why.
If you don't read documentation already, get comfortable with it now. A lot of people on StackOverflow are fucking stupid and will give you an answer that technically works but is so profoundly stupid that I would slap you with a printout of the Linux kernel just to beat some runtime sense into you. Don't blindly copy-paste and modify answers until something works, because that's how you piss off every single one of your successors who have to deal with your shit when you're gone. Read the fucking manual. Figure out why you're writing the code you're writing and what kinds of unintended side-effects might be introduced as a result. Figure out if there's a better or officially recommended solution to the problem, because maybe (i.e. likely) you don't understand the subtle nuances of how the particular technology you're working with gets its job done.
Always question your solutions, the solutions of your co-workers, and the solutions of your predecessors. Humans are idiots. We can be certified geniuses and still do stupid shit frequently. I've written code, looked it over several times, released it, and discovered vulnerabilities after the fact, because I don't take my code for granted. You're going to fuck up like that, too. Anticipate it, watch out for it, and fix your fuck-ups when you notice them.
Learn to pick your battles. Yes, your database driver has a significant bug that isn't fixed until a later version. Yes, it requires a major language version update. Yes, things will break as a result and many changes to the code will be needed. No, the company doesn't have the budget for it and there are more pressing items that need attending to. No, they're not going to budge on the point. You brought it up to them and they put the ticket in their system, so you've done all you can. It's okay for their software to screw up--it's their software, not yours. Just do what you can to make the parts you work on as good as you can and take pride in what you manage to accomplish.
Write scripts. Write lots of scripts. Seriously. I can't even begin to tell you how nice it is to have lots of bash aliases that take care of otherwise lengthy and annoying commands, or shell scripts that accept literally one argument and take care of an entire environment setup without me having to do anything. I can even go get a cup of coffee while my scripts do all of the work for me. If there's anything you use and reuse fairly frequently, write a script for it. If there's anything you use every now and then but not frequently enough to remember, write a script for it. If there are some commands you run every now and then and they're prone to errors if you're not careful, write a fucking script for it. Automate the human element out of the picture as much as possible and next thing you know you'll be wondering why the hell you didn't do that in the first place.
Get a password manager. You're going to have lots of work-related accounts to deal with and you sure as shit don't want to reuse passwords for this. If someone breaks in, they can do a ton of damage. So get a password manager, have a work profile, and secure it with 2FA. Then generate secure, random passwords for your work-related accounts. If you're on Linux and like to work with the command line, you might consider LastPass and installing the LastPass CLI.
Learn to stop working. No, seriously. Sometimes you'll get tunnel vision and even rubber duck debugging won't help worth a damn. When that happens, just walk away from your monitor. Talk to someone about something not related to your task, maybe about that movie you saw the other day. Go for a walk and get some fresh air. It's not uncommon to bang your head against a problem for hours to no avail, then think of the solution as soon as you're away from your workstation for a good 10-15 minutes.
Learn to love whiteboards. A diagram of your program logic can help you identify identical branches of logic and branches of execution that hit dead ends, and you can use those insights to reduce the redundancy and complexity of your code. If you design the diagram as a directed graph, you can also regroup nodes atomically and possibly even reorder them in order to define better functions and methods than what already exist. It's also an invaluable tool for visualizing the propagation and transformation of data throughout your application. And let's face it, our brains have fairly limited RAM available to them, so sometimes we need to write our thoughts to physical storage somewhere so we don't forget anything critical.
Impostor syndrome is common among professionals everywhere. You're going to see the intern fresh out of high school having no trouble whatsoever keeping up with you and part of you is probably going to be wondering if you even really know what you're doing because it's looking like he'll surpass you in no time. You'll have to learn not to measure yourself against your peers, and to instead measure yourself against your past self.
Your work isn't your life. Don't burn yourself out. Take time for yourself. Exercise, eat good food, have a hobby or two, just do something that isn't related to your work in any way. You're not less important than your work, so take care of yourself.
I'm sure I'm forgetting a lot of things, but hey, it's a start :)
To add on to this, whatever query you end up running should be copy-pasted into your ticket. If the fuck up is subtle you want a paper trail of what was done.
Never, ever, ever run direct database queries on production without a damned good reason
To add on to this, whatever query you end up running should be copy-pasted into your ticket. If the fuck up is subtle you want a paper trail of what was done.
To this point, write everything in a transaction that can be rolled back. I've seen too many people fat finger something, see "100k Records Affected" and the life drain out of their face. I...
To this point, write everything in a transaction that can be rolled back. I've seen too many people fat finger something, see "100k Records Affected" and the life drain out of their face. I watched one of my first managers delete half a million customer phone records (we had back ups, but was still stressful.)
Oh man, I imagine that transition had to be rough. The sudden introduction of rigid structure, development priorities that probably differ greatly from what you would normally set for yourself,...
Oh man, I imagine that transition had to be rough. The sudden introduction of rigid structure, development priorities that probably differ greatly from what you would normally set for yourself, likely going from starting projects from scratch to maintaining existing projects, having potentially multiple people to answer to instead of just a client... I'm getting flashbacks to my first day working at my internship!
I have one bit of advice that I feel should work for everybody, computer science or not: obsessively make to-do lists, every day. Handwritten, not anything in an app. My strategy is pretty much...
I have one bit of advice that I feel should work for everybody, computer science or not: obsessively make to-do lists, every day. Handwritten, not anything in an app.
My strategy is pretty much this:
A new page for each day.
Pre-name your P1 item for the day, at the start of the day. It must get done today.
If you do something not on your list that takes a reasonable portion of your time, retroactively add it to your list and cross it off.
If you complete an item check it (or cross it with a thin hairline). You might want to read it later (this helps professionally, for self reviews, particularly that P1 field.)
If an item doesn't get completed, add it to tomorrow.
When writing your list that morning, flip back a few days, and find anything you left behind that still needs attention.
(Pro-strat:) Your to-do list items should be discrete, un-blocked, next required actions only. If you are blocked, or it's part of a major project, use another resource (app, another to-do list page, etc) to track that, so your daily lists remain uncluttered and focused, and everything you can do right now.
Even though I have project/bug trackers at my disposal, adopting a personal daily to-do list in my workflow is, for me, the one thing that gave my career new direction and momentum, and crossing items as you complete them gives you an actual psychological reward. With to-do lists, I feel that I'm better able to keep to personal ideals and direction, rather just deal with things as they hit me.
(And the fun part: I use Field Notes as my exclusive notebook of choice. Their special editions are always awesome.)
I just started using Field Notes myself in a similar manner (but also included personal todos and self-improvement tasks), and it's been a big boon to my productivity levels across the board. Apps...
I just started using Field Notes myself in a similar manner (but also included personal todos and self-improvement tasks), and it's been a big boon to my productivity levels across the board. Apps just don't cut it, and you don't get the same level of satisfaction as you do with pen and paper.
I got here through your comment on the products discussion. I don't understand your pro-strategy point. What do you mean with un-blocked? And I'm also not sure what 'discrete' means in this context.
Yeah, good question! Basically, every item on your to-do list should be the immediate next thing (or lists of "next things") that you need to do, for anything. Unblocked would mean, you're not...
Yeah, good question! Basically, every item on your to-do list should be the immediate next thing (or lists of "next things") that you need to do, for anything. Unblocked would mean, you're not waiting on someone else to do something before you can get to it, or you need to set up a development environment, or etc. I mean discrete in this context to mean that your list should be separate and distinct: you're not writing down a list of projects, you're writing down separate and individually actionable tasks which help you succeed at projects you've planned elsewhere.
Not really. I used to use some formal GTD methods, but could never find an app or process that worked exactly for me, and really the biggest boon to my productivity is deliberately planning my day...
Not really. I used to use some formal GTD methods, but could never find an app or process that worked exactly for me, and really the biggest boon to my productivity is deliberately planning my day at the start of my day.
A minor chunk of my to-do items are tied to something like a bug tracking system, so I'll often handwrite the bug IDs on the list too. But mostly I just flip back a few pages to canvass for unresolved items (that are still important enough), and float them to today's page. Beyond that, I still try to get most things on the list done that day—often it's like "reply to this email", where it's just silly to add it to some formalized tracker.
I, sadly, don't have a good enough "future" list. If I'm planning a project I'm leading myself, I tend to use the notes app on my computer and braindump ideas, which then graduates to a few pages of a big notebook as I plan out implementation/workflows/tasks/etc, and then from there it becomes entries in the bug tracker or daily tasks.
Here was a pretty good thread on this topic from a few months ago. I was going to copy-paste my comment from it, but you might as well just check out the whole original thread (keeping this one up...
Here was a pretty good thread on this topic from a few months ago. I was going to copy-paste my comment from it, but you might as well just check out the whole original thread (keeping this one up is fine too, I just wanted to link to it): https://tildes.net/~comp/6cx/advice_for_those_who_want_a_computer_science_career
Hi, can I ask you a question? I am about to complete my graduation and already have a job but I have a lot of free time in between and was thinking about brushing up my skills. I am already...
Hi, can I ask you a question? I am about to complete my graduation and already have a job but I have a lot of free time in between and was thinking about brushing up my skills. I am already familiar with algorithms and data structures but don't have much practice implementing them.
On the other hand, I am working part time with a startup as a junior developer and learning all these technologies and frameworks which are being used.
So I guess my question is, what would be a better utilisation of my time (from a career perspective) - learning more about these core concepts in detail or making projects to build my portfolio?
Sorry if this is a silly question, it's just that I can't make up my mind and am wasting so much time.
In my opinion, build a project. Not even necessarily for portfolio-building purposes, just pick something you're interested in and try to build a fully usable program/app/site/whatever for it. It...
In my opinion, build a project. Not even necessarily for portfolio-building purposes, just pick something you're interested in and try to build a fully usable program/app/site/whatever for it. It doesn't need to be anything serious, it can be related to one of your hobbies, tracking scores for a video game you play, whatever.
I think that's the best way to learn, and by having it be related to something that you're interested in and want to use yourself, that should keep you more motivated to keep working on it. Implementing random algorithms and data structures is fine, but unless you end up working in a very specific type of job, it's not the sort of thing you'll ever need to do outside of interviews.
I'd second the vote for building a project. All the theory in the world is nice and all, but without it starting to mean something practical to you then you risk it not sticking in your memory. If...
I'd second the vote for building a project.
All the theory in the world is nice and all, but without it starting to mean something practical to you then you risk it not sticking in your memory. If your project hits a stumbling block and you require some theory to get over it then that's real learning that will stick with you.
In addition, if you consider outsiders looking in (maybe not right now, but future potential employers), then being able to talk passionately about a handful of projects you've built that solve a problem for you will set you apart from someone who can list a dozen esoteric books with interesting theories.
There are two paths you could take. If you are interested in eventually moving into management, I suggest you start to focus on a couple of things. Start with who & why. Who is the customer, who...
There are two paths you could take.
If you are interested in eventually moving into management, I suggest you start to focus on a couple of things.
Start with who & why. Who is the customer, who is the user and why do they want this. If the answer lacks detailed specifics, you need to get involved with actual discussions with actual users & customers. Keep in mind the customer is almost never the direct user.
Take any opportunity to present. Really dedicate some time thinking about what you will say. Practice. Present. Ask for feedback. Get better at it.
Always say yes. Offer to help out even if it does not directly benefit you. Make your boss look good. Grow your network.
I presume you have read the lean startup and all the other usual basics.
Have you already had a frank conversation with your boss regarding unrealistic timeframes? Here are my favorite books, they are all classics Positioning - The battle for your mind The Innovator's...
Have you already had a frank conversation with your boss regarding unrealistic timeframes?
Have you offered to help with t-shirt sizing? Have you suggested taking an agile approach to slicing up user stories? You are astute in your observation that I don't say yes to everything. I say...
Have you offered to help with t-shirt sizing?
Have you suggested taking an agile approach to slicing up user stories?
You are astute in your observation that I don't say yes to everything. I say yes to interesting new challenges. I say no when something is not a good fit.
I stopped "learning" and started "doing". I started attempting to break some machines from Vulnhub.com. It was really hard, even though I'd spent a long time reading about the theory. But once I'd...
I stopped "learning" and started "doing".
I started attempting to break some machines from Vulnhub.com. It was really hard, even though I'd spent a long time reading about the theory. But once I'd started actually applying it, it started to form a natural process for me and I started to build an intuition on what to try, what to focus on, what to leave alone for now.
Started writing about it
I started writing up the hacks I'd completed. This was intended originally as a means of helping me remember what I'd done but eventually I started to get readers in small-but-ok numbers. And then they started asking questions, which meant I started trying to solve other problems as part of running the blog. I became a teacher of sorts in my little microcosm and that forced me to research the things I was talking about in even more depth since I didn't want to come across like a shill or start giving people bum advice.
If your job doesn't provide you learning opportunities you have to take them yourself, take a few hours during your work to work on personal projects or better contribute to open source projects.
If your job doesn't provide you learning opportunities you have to take them yourself, take a few hours during your work to work on personal projects or better contribute to open source projects.
I am self taught, so for me it was always learning and having hobby projects going in my spare time. The other thing would be applying for jobs even if I did not tick every single point in the job...
I am self taught, so for me it was always learning and having hobby projects going in my spare time. The other thing would be applying for jobs even if I did not tick every single point in the job description.
There are a lot of things I've learned in the two short years I've been out of college and out in the workplace. Here's a non-comprehensive list:
./run_tests.shand have a test suite report back to you which of your test cases are failing and why.I'm sure I'm forgetting a lot of things, but hey, it's a start :)
To add on to this, whatever query you end up running should be copy-pasted into your ticket. If the fuck up is subtle you want a paper trail of what was done.
To this point, write everything in a transaction that can be rolled back. I've seen too many people fat finger something, see "100k Records Affected" and the life drain out of their face. I watched one of my first managers delete half a million customer phone records (we had back ups, but was still stressful.)
Excellent point! I'm definitely making a mental note of this for myself for the future :)
Oh man, I imagine that transition had to be rough. The sudden introduction of rigid structure, development priorities that probably differ greatly from what you would normally set for yourself, likely going from starting projects from scratch to maintaining existing projects, having potentially multiple people to answer to instead of just a client... I'm getting flashbacks to my first day working at my internship!
I have one bit of advice that I feel should work for everybody, computer science or not: obsessively make to-do lists, every day. Handwritten, not anything in an app.
My strategy is pretty much this:
Even though I have project/bug trackers at my disposal, adopting a personal daily to-do list in my workflow is, for me, the one thing that gave my career new direction and momentum, and crossing items as you complete them gives you an actual psychological reward. With to-do lists, I feel that I'm better able to keep to personal ideals and direction, rather just deal with things as they hit me.
(And the fun part: I use Field Notes as my exclusive notebook of choice. Their special editions are always awesome.)
I just started using Field Notes myself in a similar manner (but also included personal todos and self-improvement tasks), and it's been a big boon to my productivity levels across the board. Apps just don't cut it, and you don't get the same level of satisfaction as you do with pen and paper.
I got here through your comment on the products discussion.
I don't understand your pro-strategy point. What do you mean with un-blocked?
And I'm also not sure what 'discrete' means in this context.
Yeah, good question! Basically, every item on your to-do list should be the immediate next thing (or lists of "next things") that you need to do, for anything. Unblocked would mean, you're not waiting on someone else to do something before you can get to it, or you need to set up a development environment, or etc. I mean discrete in this context to mean that your list should be separate and distinct: you're not writing down a list of projects, you're writing down separate and individually actionable tasks which help you succeed at projects you've planned elsewhere.
Thanks for the clarification. Do you use a specific system to keep track of the status of the todo items?
Not really. I used to use some formal GTD methods, but could never find an app or process that worked exactly for me, and really the biggest boon to my productivity is deliberately planning my day at the start of my day.
A minor chunk of my to-do items are tied to something like a bug tracking system, so I'll often handwrite the bug IDs on the list too. But mostly I just flip back a few pages to canvass for unresolved items (that are still important enough), and float them to today's page. Beyond that, I still try to get most things on the list done that day—often it's like "reply to this email", where it's just silly to add it to some formalized tracker.
I, sadly, don't have a good enough "future" list. If I'm planning a project I'm leading myself, I tend to use the notes app on my computer and braindump ideas, which then graduates to a few pages of a big notebook as I plan out implementation/workflows/tasks/etc, and then from there it becomes entries in the bug tracker or daily tasks.
Here was a pretty good thread on this topic from a few months ago. I was going to copy-paste my comment from it, but you might as well just check out the whole original thread (keeping this one up is fine too, I just wanted to link to it): https://tildes.net/~comp/6cx/advice_for_those_who_want_a_computer_science_career
Hi, can I ask you a question? I am about to complete my graduation and already have a job but I have a lot of free time in between and was thinking about brushing up my skills. I am already familiar with algorithms and data structures but don't have much practice implementing them.
On the other hand, I am working part time with a startup as a junior developer and learning all these technologies and frameworks which are being used.
So I guess my question is, what would be a better utilisation of my time (from a career perspective) - learning more about these core concepts in detail or making projects to build my portfolio?
Sorry if this is a silly question, it's just that I can't make up my mind and am wasting so much time.
In my opinion, build a project. Not even necessarily for portfolio-building purposes, just pick something you're interested in and try to build a fully usable program/app/site/whatever for it. It doesn't need to be anything serious, it can be related to one of your hobbies, tracking scores for a video game you play, whatever.
I think that's the best way to learn, and by having it be related to something that you're interested in and want to use yourself, that should keep you more motivated to keep working on it. Implementing random algorithms and data structures is fine, but unless you end up working in a very specific type of job, it's not the sort of thing you'll ever need to do outside of interviews.
I'd second the vote for building a project.
All the theory in the world is nice and all, but without it starting to mean something practical to you then you risk it not sticking in your memory. If your project hits a stumbling block and you require some theory to get over it then that's real learning that will stick with you.
In addition, if you consider outsiders looking in (maybe not right now, but future potential employers), then being able to talk passionately about a handful of projects you've built that solve a problem for you will set you apart from someone who can list a dozen esoteric books with interesting theories.
There are two paths you could take.
If you are interested in eventually moving into management, I suggest you start to focus on a couple of things.
Start with who & why. Who is the customer, who is the user and why do they want this. If the answer lacks detailed specifics, you need to get involved with actual discussions with actual users & customers. Keep in mind the customer is almost never the direct user.
Take any opportunity to present. Really dedicate some time thinking about what you will say. Practice. Present. Ask for feedback. Get better at it.
Always say yes. Offer to help out even if it does not directly benefit you. Make your boss look good. Grow your network.
I presume you have read the lean startup and all the other usual basics.
Have you already had a frank conversation with your boss regarding unrealistic timeframes?
Here are my favorite books, they are all classics
Have you offered to help with t-shirt sizing?
Have you suggested taking an agile approach to slicing up user stories?
You are astute in your observation that I don't say yes to everything. I say yes to interesting new challenges. I say no when something is not a good fit.
I started attempting to break some machines from Vulnhub.com. It was really hard, even though I'd spent a long time reading about the theory. But once I'd started actually applying it, it started to form a natural process for me and I started to build an intuition on what to try, what to focus on, what to leave alone for now.
I started writing up the hacks I'd completed. This was intended originally as a means of helping me remember what I'd done but eventually I started to get readers in small-but-ok numbers. And then they started asking questions, which meant I started trying to solve other problems as part of running the blog. I became a teacher of sorts in my little microcosm and that forced me to research the things I was talking about in even more depth since I didn't want to come across like a shill or start giving people bum advice.
If your job doesn't provide you learning opportunities you have to take them yourself, take a few hours during your work to work on personal projects or better contribute to open source projects.
I am self taught, so for me it was always learning and having hobby projects going in my spare time. The other thing would be applying for jobs even if I did not tick every single point in the job description.