Programming At School vs Work
Dev Leader Weekly 81
TL; DR:
There ARE differences between coding at school vs work!
Tune into the livestream on Monday, February 3rd at 7:00 PM Pacific!
LEARN C# FOR FREE
Nick Chapsas and I are happy to announce that until the end of February, you can get my two C# courses absolutely for FREE for life! Together these courses total 11.5 hours of content helping get you started from no programming experience to able to navigate C# and build simple applications.
Thousands of students have taken these courses and given them glowing reviews, and now YOU can get them for FREE!
Some House Keeping
I've taken some feedback about the length and structure of the newsletter. I create a LOT of content throughout the week, and I enjoy being able to share my video updates with you. When I get back into writing more blog articles, those are also included in the weekly recap section of my newsletters.
I'm transitioning the weekly recaps into dedicated blog posts and a separate email that you can check out. If you enjoy the exclusive article and major updates, you're already in the right spot. If you only want a weekly digest of the articles and videos I publish once per week, you can check that out instead. This should hopefully give you more options for managing your inbox, and I can automatically publish the digest posts/newsletters separately.
If you want to check out this week's digest, you can find the post here on my site or head over to Substack to get it in newsletter format for free.
Exclusive Article: Programming At School vs Work
Where It All Started...
This topic was part of a discussion that I covered on Code Commute earlier this week and I thought it was a helpful one to dive into. You can check out the vlog entry below:
I attended the University of Waterloo for Computer Engineering between 2007 and 2012. Man, I guess I'm getting old now. But I can still remember what it was like to get homework, assignments, projects, and lab work.
The reality is: that I wasn't super into school. I didn't really enjoy the majority of courses I had and I didn't really find that I could relate to the material in a meaningful way. For the most part, I had a lot of courses that didn't really feel like they were going to help me in software development -- and that was a big factor in not being super engaged.
But I did have internships: 6 of them, totaling 24 months of work experience within my 5-year degree program. Those internships were my first taste of what's different between learning software development in school compared to work.
But it wouldn't be quite as obvious until I started my full-time career after university.
Coding At School
Yeah, coding at school is different than coding at work. But I think it's important to acknowledge that they have different end goals.
Coding at school is often about re-enforcing your understanding of concepts. As students, we're often walked through the theory, history, and reasoning for a particular topic to introduce us to the concept. We'll get notes explaining how and why something works and example situations that demonstrate it.
But for most of us, this isn't enough to solidify the concept. We need to get hands-on with it.
Being able to work on an assignment that focuses purely on the concept that was being taught allows you to:
Remain focused, eliminating other distractions/noise
Practice the implementation, so you have a better understanding of the mechanics
Troubleshoot and see things working, so you can see the concept in action
But the constraints we have in our school projects and assignments are a bit unique:
The time constraint is the due date for the assignment
There are often aren't real dependencies for you to code your project
You're almost always starting from a fresh slate
The priorities you need to balance are this project and your other school assignments (or maybe a part-time job or social life too)
So there are constraints -- but these constraints don't have all that much to do with the specific assignment you have to code up.
As a result, I found we're often encouraged to try coming up with what should feel like a perfect solution. After all, someone is going to be grading this, right? But that's not really representative of the real world.
Coding At Work
Things get a little different when you have to code at work. I've spent a lot of my career working with interns and new grads (and I was an intern many times myself) so I've seen some patterns that I think are helpful to understand.
The goal of coding things for work is no longer about building a better understanding of a concept. The goal is almost always about delivering value to customers.
Now, that's not to say you won't be learning things, getting better at your craft, or exploring different technology -- you absolutely will be! But at the end of the day, your employer is paying you to ship value to customers because customers are what keeps the business running. I've found that sometimes people joining companies that are already profitable may have a slight disconnect with the idea that value actually has to be delivered to customers and that our jobs are not just to create code.
Not only is our goal different, but our constraints look very different as well:
There may be many different time constraints. Your code is blocking something else from being delivered, your code is a fix or feature needed for a release, or your change might be affecting a live service that needs updates. Not to mention, we need to be shipping value to customers -- so we can't wait indefinitely to get things out the door!
There are often many dependencies! Not only are we faced with literal dependencies in code, but sometimes we're blocked on other team members or teams that need to deliver work first. We might even have to wait on deployment schedules or other external factors. Dependencies are a HUGE part of navigating work on projects.
You're almost never starting a fresh slate, statistically. Now this will vary based on the type of work you do, but the majority of us spend a very large part of our career maintaining and building existing large software systems. That means you need to dive into a HUGE code base instead of pressing "new project" in your IDE.
There are often many priorities to balance. Not only might you have multiple projects you're active on, but the business itself might be changing priorities as you're working on delivering things.
So yes, we're still writing code. Yes, we're still building software. But how it looks can be very very different.
Takeaways
Now that we've gone over some of the differences, let's quickly go over some of my advice to take away from this. This will be framed for students preparing for "the real world" when they’re coding on the job, whether that's their first internship or full-time role:
There is a point of diminishing returns with trying to make code perfect. It should do its job, be readable, and be testable. There isn't a perfect score that someone's going to assign you, so get it shipped.
Learn how to navigate code bases. This is a skill that you need to practice so you don't feel overwhelmed every time you need to start a new task. You'll be spending most of your time in existing code bases!
Try to understand your dependencies and how they affect the work you need to do. How does your work fit into the bigger picture, and what does that picture look like when you start factoring in the work of others?
Sometimes a solution to a problem might seem super simple, but because of real-world constraints (i.e. we can't press pause for all of the users so you can redeploy a fix and migrate the database all at the same time) you need to get more creative.
It's also worth mentioning that as you become more senior, you'll be given far more ambiguous problems. Instead of something like a school assignment that tells you to implement some algorithm using C#, you'll have tasks like "Reduce the overall latency of the system by 30%". You'll want to get good at decomposing big ambiguous problems into smaller, more digestible ones.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!