Professional coding: what should I expect?

I've graduated recently and just got a job in a big software company (red one, hates API's ). Now I was wondering what should I expect upon starting my life in this strange, new, corporate world. Any tips anybody wishes somebody told them when they were starting?

Coding for 8 hours a day takes some getting used to.After a year or two you will think you know everything. You are wrong.There are fads in programming. Learn the new stuff, but don't think it's the One True Way. It's not.

On the plus side, you will learn more about the practical side of software development during your first month on the job than you did in your entire degree program.

Otherwise, prepare to have many illusions shattered.

This is still probably my favorite description of what it's like to work in software. It's not all doom and gloom, of course, but software's still a relatively immature industry, and it shows. We're still trying to figure out the Best Way to do something, but the technology changes so rapidly that it's hard to keep up. What was the right answer for monolithic apps running on minis and mainframes is not the right answer for microservices running on a dozen different platforms. Mechanical and electrical engineers have an advantage in that they are ultimately limited by the laws of physics - we don't have that luxury.

- Learn to communicate, both verbally and in writing. The better you are at this, the better your job prospects are.

- Understand that ultimately you are in service to users, whether those are at the business you work for, clients you're delivering software to, or "the public" if you get into shrinkwrapped software development. Many, many times in your career you will be faced with a choice between doing something in a way that is easier for you / more clean for the code/architecture, or in a way that is better for the end user. Always choose the end user *first* then figure out how to code it or architect it cleanly.

- Your five-year plan needs to include determining if you have the capability to manage people and if you are interested in managing people. If you can manage and want to manage, work toward management. If you can't or won't, you need to specialize in something. Go deep in a technology or business vertical, learn to architect, whatever. You just need to know if your career will aim toward management or if you will stay technical. You should be able to figure that out in about 5 years. If you are very good at communication and putting the user first, seriously consider the management path.

Edit: LOL, jbode's link is so, so true.

Spoiler: show

Quote:

Imagine joining an engineering team. You're excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he's involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don't worry, says Mary, Fred's going to handle the walkways. What walkways? Well Fred made a good case for walkways and they're going to add to the bridge's appeal. Of course, they'll have to be built without railings, because there's a strict no railings rule enforced by Phil, who's not an engineer. Nobody's sure what Phil does, but it's definitely full of synergy and has to do with upper management, whom none of the engineers want to deal with so they just let Phil do what he wants. Sara, meanwhile, has found several hemorrhaging-edge paving techniques, and worked them all into the bridge design, so you'll have to build around each one as the bridge progresses, since each one means different underlying support and safety concerns. Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it's become a case of "whoever got to that part of the design first." This has been such a headache for the people actually screwing things together, they've given up and just forced, hammered, or welded their way through the day with whatever parts were handy. Also, the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they're still sort of holding up parts of the bridge. Nobody knows which parts, but everybody's pretty sure they're important parts. After the introductions are made, you are invited to come up with some new ideas, but you don't have any because you're a propulsion engineer and don't know anything about bridges.

On the plus side, you will learn more about the practical side of software development during your first month on the job than you did in your entire degree program.

Otherwise, prepare to have many illusions shattered.

This is still probably my favorite description of what it's like to work in software. It's not all doom and gloom, of course, but software's still a relatively immature industry, and it shows. We're still trying to figure out the Best Way to do something, but the technology changes so rapidly that it's hard to keep up. What was the right answer for monolithic apps running on minis and mainframes is not the right answer for microservices running on a dozen different platforms. Mechanical and electrical engineers have an advantage in that they are ultimately limited by the laws of physics - we don't have that luxury.

- Learn to communicate, both verbally and in writing. The better you are at this, the better your job prospects are.

- Understand that ultimately you are in service to users, whether those are at the business you work for, clients you're delivering software to, or "the public" if you get into shrinkwrapped software development. Many, many times in your career you will be faced with a choice between doing something in a way that is easier for you / more clean for the code/architecture, or in a way that is better for the end user. Always choose the end user *first* then figure out how to code it or architect it cleanly.

- Your five-year plan needs to include determining if you have the capability to manage people and if you are interested in managing people. If you can manage and want to manage, work toward management. If you can't or won't, you need to specialize in something. Go deep in a technology or business vertical, learn to architect, whatever. You just need to know if your career will aim toward management or if you will stay technical. You should be able to figure that out in about 5 years. If you are very good at communication and putting the user first, seriously consider the management path.

Edit: LOL, jbode's link is so, so true.

Spoiler: show

Quote:

Imagine joining an engineering team. You're excited and full of ideas, probably just out of school and a world of clean, beautiful designs, awe-inspiring in their aesthetic unity of purpose, economy, and strength. You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he's involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don't worry, says Mary, Fred's going to handle the walkways. What walkways? Well Fred made a good case for walkways and they're going to add to the bridge's appeal. Of course, they'll have to be built without railings, because there's a strict no railings rule enforced by Phil, who's not an engineer. Nobody's sure what Phil does, but it's definitely full of synergy and has to do with upper management, whom none of the engineers want to deal with so they just let Phil do what he wants. Sara, meanwhile, has found several hemorrhaging-edge paving techniques, and worked them all into the bridge design, so you'll have to build around each one as the bridge progresses, since each one means different underlying support and safety concerns. Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it's become a case of "whoever got to that part of the design first." This has been such a headache for the people actually screwing things together, they've given up and just forced, hammered, or welded their way through the day with whatever parts were handy. Also, the bridge was designed as a suspension bridge, but nobody actually knew how to build a suspension bridge, so they got halfway through it and then just added extra support columns to keep the thing standing, but they left the suspension cables because they're still sort of holding up parts of the bridge. Nobody knows which parts, but everybody's pretty sure they're important parts. After the introductions are made, you are invited to come up with some new ideas, but you don't have any because you're a propulsion engineer and don't know anything about bridges.

Ok... I'll think about it. A priori not a huge fan of management but I'll see, thanks for the advice.

Forgot to add the most important piece of advice I can give anyone: the key to being happy in software (or any job, frankly) is to always work for people smarter than you. Those are the jobs that will challenge you, force you to learn new skills, and keep your mind sharp. You don't want to be the smartest guy in the room, especially not at this point. You don't want to spend twenty years maintaining the same, frozen-in-amber code.

As a freshout you are going to get a bunch of boring maintenance tasks (at least that's what you should be getting). This is a normal apprenticeship period, and it's to get you familiar with the code base and any processes and procedures. You're not going to spend all day every day coding - you'll be going to meetings, doing some training, reading (or, if you're me, ignoring) lots and lots and lots and lots of emails, troubleshooting, and coordinating with other teams (QA, product development, operations, etc.).

There are enough good software jobs out there that you shouldn't tolerate being in a bad one.

Like everyone else, programmers follow a normal distribution - most of us are average, a few are truly great, a few are truly incompetent. When you realize the guy who wrote the library you're linking to is probably no more skilled or intelligent than you are, you start to see modern software for the house of cards it is, just waiting for a stiff breeze to knock everything over. Again, that's not to scare you off or anything, it's just to prepare you for reality. There are plenty of worse ways to make a living.

You don't need to be friends with your co-workers. You do need to be friendly, or at least cordial. Participating in the golf league or corporate fun run is one way to network, but not the only way.

I didn't learn version control in school. I needed it immediately in industry.

You will be asked to make estimates and report status updates. Those activities are unpleasant, but it's not unreasonable for your employer to want to know how long something will take, and how you're doing.

Get used to formal design and documentation. They are not fun, but they are important. As things change, try to keep design & docs up-to-date.

Don't let your "tools" impair your productivity. Plain text documents and photographs of whiteboard sketches are in many cases perfectly adequate design artifacts, at least in the early stages. MS Word templates eat hours and only add value when a document has to be customer-facing.

There will be many times when you find yourself "blocked" on a task while you wait for someone else to finish something or get back to you. Your happiness and productivity may rely on how you handle these situations. Ideally you can remain flexible and work on something else while you're waiting, but not so flexible that your co-workers walk all over you and your part of the schedule begins to slip.

Ask for tools if you need them. You're not a starving student anymore - your org can afford software licenses and a second monitor.

Don't medicate stress with alcohol, and don't use sick days/PTO for hangovers. Missing work carries a much greater cost than missing class. If necessary, adjust your party/weekend habits accordingly.

Pick a target date retirement fund and max out your savings/contributions while your expenses are low.

- Your five-year plan needs to include determining if you have the capability to manage people and if you are interested in managing people. If you can manage and want to manage, work toward management. If you can't or won't, you need to specialize in something. Go deep in a technology or business vertical, learn to architect, whatever. You just need to know if your career will aim toward management or if you will stay technical. You should be able to figure that out in about 5 years. If you are very good at communication and putting the user first, seriously consider the management path.

Ok... I'll think about it. A priori not a huge fan of management but I'll see, thanks for the advice.

FWIW, I just barely dipped my toe into management waters about 15 years ago, and it was a total disaster for everyone involved. I hated it, I had no feel for it, and I responded by shutting down completely and not dealing with issues that were piling up. It is definitely not for everybody. I am much happier on the technical side of things.

Ok... I'll think about it. A priori not a huge fan of management but I'll see, thanks for the advice.

I wasn't either for a long time. 17 years later many of my friends are management in their various fields and tell me I have all the soft skills to be a great manager. I'm waaaay behind the power curve getting into management but I'm working on going that direction.

My point is just that you should keep it in mind, because at 5 years into your career you'll be like a mid-to-senior level person. If you think you might want to go management, you should start pursuing team lead opportunities. If you know you don't, you should pick an area of specialty.

That assuming you want to advance your career in one way or another. You can definitely also just be a line programmer cranking out code and paying your bills.

Edit: Things can also go jbode's way. The sooner you get some direction on whether you can and should manage the better. If you can't or shouldn't, knowing that will help you avoid getting Peter Principled.

As a freshout you are going to get a bunch of boring maintenance tasks (at least that's what you should be getting). This is a normal apprenticeship period, and it's to get you familiar with the code base and any processes and procedures. You're not going to spend all day every day coding - you'll be going to meetings, doing some training, reading (or, if you're me, ignoring) lots and lots and lots and lots of emails, troubleshooting, and coordinating with other teams (QA, product development, operations, etc.).

There is tons of good advice in the thread, but this little bit stands out as particularly important. Even very smart and successful CS majors have a long learning ramp-up once they go pro. Many of the skills, particularly some that are related to 'coding in the large', aren't really taught at school. Try to be humble, even if you are very smart, you most likely have a lot to learn.

Also, there is a lot of machismo bashing of the profession and code quality (everything is terrible, all the time), but don't take it too much to heart. Quite a lot about what is good software is actually known, and quite a lot of software is good.

Also, there is a lot of machismo bashing of the profession and code quality (everything is terrible, all the time), but don't take it too much to heart. Quite a lot about what is good software is actually known, and quite a lot of software is good.

This is true. I know for me personally, every time I go back later and look at code I wrote, say, a year ago, I think "man, what idiot wrote that?"

But I've been cranking out code that works for 17 years now. So while I may think my code is bad, it's not WTF code that does nothing.

I probably should apologize for being such a downer in this thread - I'm having to integrate services from several other teams from the mothership into our code, and it's been...slow. For one of those services, it took the better part of a year just to get the right connection information, several more months to get specs, and once we finally get everything ready to deploy on our side, they tell us that oh, wait, their side won't be in production until Q3.

And that's been cake compared to the other service, which I still don't have adequate documentation on, and none of the examples they've provided so far work at all.

Working with third-party vendors is orders of magnitude easier and more pleasant than working with our own people.

But, you know, this is reality. Modern software is highly interdependent, and you find yourself constantly being blocked by somebody else's lossage. Hence the "everything everywhere is broken all the time" attitude in the "Programming Sucks" article. It's not untrue, but that doesn't mean you can't do useful and productive things. It just means that sometimes you have to be creative and work around broken stuff.

Which brings us to the following: paradigms come and go, but legacy code is forever. There are plenty of mission-critical COBOL systems dating from the 19 freaking 70s that are still in use by major Fortune 500 companies, the kinds of systems where downtime is measured in tens of millions of dollars per minute. These systems will be hidden behind shiny new wrappers using up-to-the-minute technology, but the core application itself will never be rewritten. The cost and risk of doing so is simply too great - getting it wrong could sink the company completely.

This is also why some obviously broken shit never gets fixed. As Welch puts it:

Quote:

You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat.

IOW, fixing the original problem means potentially breaking all the workarounds, which could break something else down the line. You set up this massive ripple effect throughout the entire ecosystem. It's easier to live with the half-assed workaround than face a long weekend of frantic patching after fixing the original problem breaks your code.

Again, I promise I'm not trying to scare you off or make it sound like you've made a bad career choice; like I said earlier, there are far worse ways to make a living. But there are days where it can really be challenging. I just want you to be aware of what some of those challenges are.

I probably should apologize for being such a downer in this thread - I'm having to integrate services from several other teams from the mothership into our code, and it's been...slow. For one of those services, it took the better part of a year just to get the right connection information, several more months to get specs, and once we finally get everything ready to deploy on our side, they tell us that oh, wait, their side won't be in production until Q3.

And that's been cake compared to the other service, which I still don't have adequate documentation on, and none of the examples they've provided so far work at all.

Working with third-party vendors is orders of magnitude easier and more pleasant than working with our own people.

But, you know, this is reality. Modern software is highly interdependent, and you find yourself constantly being blocked by somebody else's lossage. Hence the "everything everywhere is broken all the time" attitude in the "Programming Sucks" article. It's not untrue, but that doesn't mean you can't do useful and productive things. It just means that sometimes you have to be creative and work around broken stuff.

Which brings us to the following: paradigms come and go, but legacy code is forever. There are plenty of mission-critical COBOL systems dating from the 19 freaking 70s that are still in use by major Fortune 500 companies, the kinds of systems where downtime is measured in tens of millions of dollars per minute. These systems will be hidden behind shiny new wrappers using up-to-the-minute technology, but the core application itself will never be rewritten. The cost and risk of doing so is simply too great - getting it wrong could sink the company completely.

This is also why some obviously broken shit never gets fixed. As Welch puts it:

Quote:

You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat.

IOW, fixing the original problem means potentially breaking all the workarounds, which could break something else down the line. You set up this massive ripple effect throughout the entire ecosystem. It's easier to live with the half-assed workaround than face a long weekend of frantic patching after fixing the original problem breaks your code.

Again, I promise I'm not trying to scare you off or make it sound like you've made a bad career choice; like I said earlier, there are far worse ways to make a living. But there are days where it can really be challenging. I just want you to be aware of what some of those challenges are.

No need to apologize. Man that thing you described at the start sounds awful, one quick question though. Isn't agile supposed to avoid such scenarios? And related, how likely is that I end up working good ol' waterfall?

As a freshout you are going to get a bunch of boring maintenance tasks (at least that's what you should be getting). This is a normal apprenticeship period, and it's to get you familiar with the code base and any processes and procedures. You're not going to spend all day every day coding - you'll be going to meetings, doing some training, reading (or, if you're me, ignoring) lots and lots and lots and lots of emails, troubleshooting, and coordinating with other teams (QA, product development, operations, etc.).

There is tons of good advice in the thread, but this little bit stands out as particularly important. Even very smart and successful CS majors have a long learning ramp-up once they go pro. Many of the skills, particularly some that are related to 'coding in the large', aren't really taught at school. Try to be humble, even if you are very smart, you most likely have a lot to learn.

Also, there is a lot of machismo bashing of the profession and code quality (everything is terrible, all the time), but don't take it too much to heart. Quite a lot about what is good software is actually known, and quite a lot of software is good.

Congrats, welcome to the field, and good luck!

Thanks man. At school we did do a lot of projects, some with actual costumers, here's hoping that that helps me with the ramp up.

Ok... I'll think about it. A priori not a huge fan of management but I'll see, thanks for the advice.

I wasn't either for a long time. 17 years later many of my friends are management in their various fields and tell me I have all the soft skills to be a great manager. I'm waaaay behind the power curve getting into management but I'm working on going that direction.

My point is just that you should keep it in mind, because at 5 years into your career you'll be like a mid-to-senior level person. If you think you might want to go management, you should start pursuing team lead opportunities. If you know you don't, you should pick an area of specialty.

That assuming you want to advance your career in one way or another. You can definitely also just be a line programmer cranking out code and paying your bills.

Edit: Things can also go jbode's way. The sooner you get some direction on whether you can and should manage the better. If you can't or shouldn't, knowing that will help you avoid getting Peter Principled.

I'll keep it in mind. The thing that annoys me about the prospect of advancing in management is that I guess at some point you get to deal with The Client hahaha. It's just that the ones I've met are, let's say, difficult and aimless

I probably should apologize for being such a downer in this thread - I'm having to integrate services from several other teams from the mothership into our code, and it's been...slow. For one of those services, it took the better part of a year just to get the right connection information, several more months to get specs, and once we finally get everything ready to deploy on our side, they tell us that oh, wait, their side won't be in production until Q3.

And that's been cake compared to the other service, which I still don't have adequate documentation on, and none of the examples they've provided so far work at all.

Working with third-party vendors is orders of magnitude easier and more pleasant than working with our own people.

But, you know, this is reality. Modern software is highly interdependent, and you find yourself constantly being blocked by somebody else's lossage. Hence the "everything everywhere is broken all the time" attitude in the "Programming Sucks" article. It's not untrue, but that doesn't mean you can't do useful and productive things. It just means that sometimes you have to be creative and work around broken stuff.

Which brings us to the following: paradigms come and go, but legacy code is forever. There are plenty of mission-critical COBOL systems dating from the 19 freaking 70s that are still in use by major Fortune 500 companies, the kinds of systems where downtime is measured in tens of millions of dollars per minute. These systems will be hidden behind shiny new wrappers using up-to-the-minute technology, but the core application itself will never be rewritten. The cost and risk of doing so is simply too great - getting it wrong could sink the company completely.

This is also why some obviously broken shit never gets fixed. As Welch puts it:

Quote:

You discover that one day, some idiot decided that since another idiot decided that 1/0 should equal infinity, they could just use that as a shorthand for "Infinity" when simplifying their code. Then a non-idiot rightly decided that this was idiotic, which is what the original idiot should have decided, but since he didn't, the non-idiot decided to be a dick and make this a failing error in his new compiler. Then he decided he wasn't going to tell anyone that this was an error, because he's a dick, and now all your snowflakes are urine and you can't even find the cat.

IOW, fixing the original problem means potentially breaking all the workarounds, which could break something else down the line. You set up this massive ripple effect throughout the entire ecosystem. It's easier to live with the half-assed workaround than face a long weekend of frantic patching after fixing the original problem breaks your code.

Again, I promise I'm not trying to scare you off or make it sound like you've made a bad career choice; like I said earlier, there are far worse ways to make a living. But there are days where it can really be challenging. I just want you to be aware of what some of those challenges are.

No need to apologize. Man that thing you described at the start sounds awful, one quick question though. Isn't agile supposed to avoid such scenarios? And related, how likely is that I end up working good ol' waterfall?

Proper communication at the business level would have avoided this particular scenario - we wanted to deploy in Q1, had to delay to Q2 because of issues during development, and weren't told that the other side wasn't ready to go to production until a week before we were due to drop. And this is nothing. This is just the normal shit everybody has to deal with at some point. Disorganization is a fact of life on large projects. It's when customers or third parties act maliciously (such as throwing up last-minute requirements changes and then threatening to sue if you miss the original deadline) that things get awful1.

When you're relying on a third party to provide a critical piece of functionality (without which you don't have anything to deploy), and that third party is either dragging their feet or too busy putting out their own fires, it doesn't really matter whether you're agile or not. You can only control your own destiny.

AFAIK, traditional waterfall is pretty much dead in all but a few spaces. My last project in the military industrial complex followed a spiral development plan, where features and functionality would be rolled out in phases, with feedback from the warfighters informing the next phase. Not really agile, not really waterfall - no continuous integration, no scrums. In the MIC you have the third-party problem out the wazoo with dozens of different contractors, scores of project managers, military and government red tape, and the ever-present threat of Congress nuking your funding (projects get cancelled all the time - not every project is the F-35). The advantage of being at the bottom of the bottom in those projects is that you don't have to respond to every email and you don't have to hop on to every teleconference or go to every meeting - you get to spend at least a couple of hours a day actually writing code.

...I'm being negative again...

Anyway, agile's great (in theory) when you're entirely in control of your own destiny. I'm not - my particular subsystem is defined by interacting with third parties, so I'm entirely at the mercy of other people outside of my organization getting their shit to work (which they usually do, and in a timely manner).

1. That project damn near put me in the hospital. Never, ever work for academics - they are awful, evil, horrible people.

Isn't agile supposed to avoid such scenarios? And related, how likely is that I end up working good ol' waterfall?

It's hard to say. IME, a highly likely outcome is you'll be on a process that's somewhere between the two. The age of the codebase will dictate how close you are to one end or the other.

Also, you'll have a very strong desire to make things better. There's nothing wrong with that, but if the code is old and "working", suppress that desire -- especially if the test coverage isn't great. It's easy to introduce unintended consequences in innocent looking code. You'll probably break something unintentionally while doing what you're supposed to -- don't do it doing something you weren't.

Quote:

At school we did do a lot of projects, some with actual costumers, here's hoping that that helps me with the ramp up.

That's useful experience to have, but if it was all greenfield development it's very different from legacy maintenance.

Quote:

I'll keep it in mind. The thing that annoys me about the prospect of advancing in management is that I guess at some point you get to deal with The Client hahaha. It's just that the ones I've met are, let's say, difficult and aimless

If you're a decent communicator and not a creepy slob you'll end up getting tapped for that duty at some point anyway. That's a good thing. Just remember that most of the time they don't know what they want. Even if they think they know what they want they might not realize what their available options are. The best thing you can do will be to listen, to read between the lines, and give them not just what they asked for, but what they didn't realize they needed.

Also: Even if the client doesn't understand what you do, they do understand what they do much better than you. You're much more valuable to the client if you take some time to understand what they do.

Your attitude can help carry you or bury you. Be prepared to disagree on something but try not to take it personally. If you're on the "losing" side of a decision, get on board with the team and don't mope about it or bring it up whenever there is a problem.

If there's something that everyone else is wrong about except you, figure out what you're missing

I'll keep it in mind. The thing that annoys me about the prospect of advancing in management is that I guess at some point you get to deal with The Client hahaha. It's just that the ones I've met are, let's say, difficult and aimless

Clients (internal or external) generally know two things of use to you:

1. How their business (or piece of the business) works.2. The problems in their business (or piece of the business) that they'd like solved.

They also generally *don't* know two things you wish they did:

1. How their business (or piece of the business) fits into the bigger picture.2. How to solve the problems they'd like solved.

Many, many bad interactions with clients come from the expectation that they know the things they don't. #1 bites you when somebody from a department has a wishlist and you implement it, only to find out you have business process integration problems with some other part of the business. #2 bites you because they think they know how to solve the problem but don't really. So you get specs that don't make sense, or you get specs that do make sense and you build what they asked for but it doesn't really solve the problem, or they get super unrealistic expectations about how long a fix will take, etc.

I learned a great trick from my last boss--when he'd be meeting with people in other departments and they started going into technical details about how something should work, he'd back them up and say something like "I just need you to describe the problem and what the output should look like. Let us worry about how to make that happen." That was a key idea to making our programming projects run more smoothly.

I'm perhaps in a good position to answer your question, because I'm in a similar boat. Still in school, but with experience working in the industry at the same time.

You should have chose a program with a paid co-op option so you could have learned all this stuff while still in the stage where you have the support of your school, where your co-op employer expects that you'll make major fuckups, and with the expectation that you don't fully understand business culture. But too late for that now.

I'll be starting my second co-op this fall, got hired part-time by my last co-op employer to work over the school year (with an hourly rate about equivalent to a fresh CS grad in my city), and I've picked up many of these lessons already. Number one lesson is that very little you learn in school will apply to the working world. Things are way messier, for a huge number of reasons, almost all of which are out of your control. In my particular case, I'm thrown from project to project fairly frequently (I work in academia [but much of it is applied, with the end goal of a patentable product], so things are even messier than what most of what these guys are saying), so time management and prioritization becomes ultra important. Figuring out what your boss needs done right now versus at the end of the week, even when s/he doesn't say it, is hugely important. In North American business culture, people are very indirect and will never tell you clearly what they mean, especially if it's about negative performance. The feedback sandwich is very real, and it's very shitty, so understand when you are being fed it. For proof that people are indirect, just think about your job title. I bet it does not describe what you do in the slightest.

But I'm in no respects completely acclimated to the industry. I still have a ways to go.

Number one lesson is that very little you learn in school will apply to the working world.

I've said it before, a CS degree is not a degree in programming; it's actually a fairly baroque math degree.

For people who do not intend to pursue Computer Science as an academic endeavor in grad school and beyond, the chief value of a CS degree is that it primes your brain to learn new technology fairly easily. As I said earlier, you'll learn more about the practical side software development in your first month on the job than you did in your entire degree program. Most of what you learned in school will apply, just not directly.

Number one lesson is that very little you learn in school will apply to the working world.

I've said it before, a CS degree is not a degree in programming; it's actually a fairly baroque math degree.

For people who do not intend to pursue Computer Science as an academic endeavor in grad school and beyond, the chief value of a CS degree is that it primes your brain to learn new technology fairly easily. As I said earlier, you'll learn more about the practical side software development in your first month on the job than you did in your entire degree program. Most of what you learned in school will apply, just not directly.

I do think have a computer science background can be invaluable in learning and understanding how to then apply real world solutions to problems. I've found it invaluable, although I have never professionally ever had to implement a bubble sort or linked list or a tree or anything like that. But, having the background to understand how they operate in principle has been very useful to know in order to help pick the right data structure and how to apply the algorithm to it and vice versa.

the chief value of a CS degree is that it primes your brain to learn new technology fairly easily

A lot of truth in this. A good CS education and a good book on computer architecture (hello Inside the Machine!) will take you a long way.

Also agree. I've told people my whole career that a CS degree doesn't prepare you for a job. It teaches you how to think like a programmer, which makes the languages and APIs you use in your career much easier to pick up and understand.

I have two interns right now, so some of this is a result of the saliency of the experience of being in the position of a career manager, mentor, and technical reviewer. I'm lucky enough to be surrounded by people who have kept my rate of learning very high, and I learned a lot of these lessons by making a fool of myself. In fact, they're almost all mistakes that I made personally.

--

1) You probably have some idea of where you stand in the world. How your aptitude stacks up against everyone else. Throw those ideas away. Until now, you've been in ponds that are populated by beginners. (Beginners with a lot of aptitude are still beginners.) You'll be working with people who have forgotten more than you've ever learned. Dunning Kruger is a thing, especially in people who don't really understand just how big the global pond is.

--

2) The bar where you can say that you "know" something is now WAY higher. A semester of playing with Python or OCaml or whatever isn't sufficient to say that you "know" one of those languages. At best, those languages are casual acquaintances.

--

3) The hard stuff is going to be the "craftsmanship". I.e. the stuff you can't read in a book. The knowledge that has to be earned by simply doing the work. Books will give you the language to describe ideas, but that usually only works looking backwards to better understand a challenge you had, or an experience that was meaningful to you. Similarly, you may be able to conceptually see how to get from A to B, but actually building that Idea Bridge will probably frustrate you in the beginning. "This should be easier" will subside with time, and the "hard stuff" will be getting the design and cross-component interactions right. Just like writing words, expressing ideas in code will get easier with time. Kicking yourself is counter-productive. Ask for help if you get stuck. Sometimes all you need is some boxes and arrows drawn on a whiteboard.

--

4) Your internal "this feels wrong" compass will undergo some recalibration. You will come across people who are less clever than you, who may not be able to explain why approach A is better than approach B. That doesn't mean they're wrong, and you are right. At the beginning of my development career, I learned this with dependency injection which was so different than anything seen or done to that point. The person couldn't explain it beyond "it makes your code more testable", and I discounted his PoV because I knew I was cleverer than he was. Looking back, he did it mechanically, because that was what we were supposed to do. Knowing what I know now, I understand the hows and whys, and I write code that's very testable. (Some would say overengineered.) I came full circle, and do what he did; the difference is that I know understand the "why" at all levels of abstraction, but functionally the outcome is the same: I write code that looks like how he was writing it. I shouldn't have declined his pull requests, and my squad lead should have intervened to explain what, how, and why, instead of letting us bicker amongst ourselves. So, two failures there: one on me, one on my squad lead. Notice who wasn't at fault? The guy refactoring my code.

And sometimes your "this feels wrong" compass will be right. What you do from there is another matter, because sometimes doing the locally-wrong thing is the right thing to do to enable a business outcome.

--

5) Learn how to ask good questions. Learn how to not know things. Yes, that really is a skill. Learn to self-learn, if you don't already. Learn to JIT your learning.

--

6) Don't chase trends. Use battle-proven technologies. Churn is not adding value. Porting a component from platform A to platform B is just rearranging furniture, unless it is a concrete step to enabling a better future. And make sure that better future is tied to a real business outcome, otherwise you're just building beautiful sand castles.

--

7) Learn more than one programming paradigm. If you're most familiar with object-oriented development, it's time to learn functional programming. Even if you don't use it daily, it will change the way you think. This is so, so valuable.

--

8) Optimize your career to maximize your learning. If you're having the same year of experience over and over again, it's probably time to find another group or company. If you optimize your career for rate of learning, you maximize the possibilities and opportunities that are available to you. It's a virtuous feedback loop.

--

9) Learn how your tools work under the hood. As an example: maybe you know the basic git commands, but do you understand the underlying object model? I don't think you can say you "know git" until you can draw the directed graph of the state that your local repository is in at any given time, and you can draw the future state that you want your repository to be in, and then use the CLI to get you from the present state to the future state. If you can do that, you understand the basics of git. I apply this same kind of heuristic to everything technical.

Corollary: learn when it's not valuable to know the details of something.

--

10) Building off of #9, don't memorize things. (Except maybe the standard library of your bread-and-butter programming language(s).) If you can't reason your way to a solution from first principles, you don't really understand whatever it is you're working on. Reasoning from first principles will take you a lot further than rote memorization, but building these foundations takes time. Take the time, when the opportunity presents itself.

--

11) You can't always jump exactly to exactly where you want to be, but you can get there by taking baby steps towards the thing you think you'd like to do. I call this the "adjacent possible". Maybe you can't land in the precise group you wanted to be in. But you can land in a group adjacent to it that works closely with that other group. Make that leap, do good work, and keep your ear to the ground. When an opening is available in the space you really want to be in, you'll have the credibility and experience to make it easier for the relevant managers to say "yes".

--

12) Call it credibility, call it social capital. Whatever word you choose, remember that it's like a bank account: you must make deposits before you make withdrawals. As a new developer, you have the $100 the bank gave you for opening an account, and that's it. Where you go from there is up to you.

Corollary: the more uncomfortable the situation, the higher the multiplier is for action you're about to take. It's up to you to decide whether the sign is positive or negative.

--

13) A general dissatisfaction with the status quo is healthy. Temper that with the understanding that stopping the world to change A or B just isn't in the cards. Incremental improvements are the name of the game when it comes to legacy systems. "Boy scout" when the opportunity presents itself. (I.e. leave the code better than it was when you arrived.) On the other hand, marching into someone else's back yard and redoing the landscaping is considered bad form, unless you absolutely must, so maybe stick to your own yard, unless it's paving the way to a future. And make sure that better future has management buy-in.

Corollary: all change introduces risk, including changes meant to reduce overall risk. That doesn't mean you shouldn't do make the change, but your motivation should be something more than scratching a personal itch.

Management done well is hard, but it's worth it. When you work at a place that does it well, the idea of 1) going without management or 2) going to a place with bad management is absolutely insane. Good managers clear the space so their people who do the actual work can do the actual work.

If this doesn't happen for you frequently, something's wrong. You're either a demigod or an idiot. Whichever one you think of yourself is probably incorrect.

There are exceptions, of course. You've probably got them in a file somewhere. The same one referenced in jbode's link.

This doesn't really happen to me anymore, at least when it comes to the implementations of things. Happens all the time when looking at overall design, though. I think that reflects the general trend of #3 of my brain dump above. I find there's two basic roots for poor up-front design: 1) ignorance about how the domain/use cases would unfold (we're not clairvoyant, and neither is the consumer of the things we make) or 2) ignorance about the domain more generally (remedied by getting experience in the space). Neither are "problems", per se; it's just the human condition applied to code.

As we learn, we make different mistakes. This is no different than, say, parenting.

I'll keep it in mind. The thing that annoys me about the prospect of advancing in management is that I guess at some point you get to deal with The Client hahaha. It's just that the ones I've met are, let's say, difficult and aimless

It's likely you'll deal with clients within your first year. This is why you need good communication skills. A lot of developers argue that you should have mechanical sympathy. I would suggest that sympathy for the client is more important for you personally, and for business outcomes as well.

Sometimes developers forget that they're on the same team as the client. You're not adversaries, you're collaborators.

If you don't know something, ask. I don't know how many times I've come across people that don't ask questions out of a fear of being called stupid or some other nonsense.

Especially in classrooms this is very much a thing.

Yeah, this is a really good point.

In Academia, there's benefit to being the smartest person in the room. In the workplace, the benefit is being the most productive person in the room. Nobody cares if you're smart, people care if you write good code. Since you're new, they expect questions. Not asking questions is a red flag. Sitting there stuck because you don't want to ask questions is a *huge* red flag.

I've been doing this for 18 years now, and my personal threshold is about 30 minutes. If I'm stuck on something for more than 30 minutes, I get somebody else to help, no matter how dumb it might seem.

I'll keep it in mind. The thing that annoys me about the prospect of advancing in management is that I guess at some point you get to deal with The Client hahaha. It's just that the ones I've met are, let's say, difficult and aimless

It's likely you'll deal with clients within your first year. This is why you need good communication skills. A lot of developers argue that you should have mechanical sympathy. I would suggest that sympathy for the client is more important for you personally, and for business outcomes as well.

Sometimes developers forget that they're on the same team as the client. You're not adversaries, you're collaborators.

I am infamous for being a little too honest with clients - "hey, you think that's bad, let me show you this broken shit...". I understand their frustration - I'm just as frustrated, if not more so (reference my latest rant in the "while (true) {" thread). However, there's a line you really shouldn't cross - you want your clients to trust you, and they won't do that if you're constantly badmouthing your own code.

Upside is that I don't get sent to client sites very often anymore (spend 48 hours traveling to and from Tokyo for a whole 8 hours on site, or eight weeks at sea on a drill ship, and your tolerance for travel goes down real quick).

But yeah, depending on where you work and what you're working on, prepare to have to interact with clients early on. They're not bad people (well, most of them aren't). The worst you can say about most of them is that they're just disorganized, or not quite sure what they want. Your job (well, your BA's job) is to help them figure out what they really want, and then deliver on that vision. You won't be 100% successful. Clients will get frustrated. This is normal. We're humans, we screw up a lot, especially in software. How you respond to the situation is what matters (which means not saying, "hey, you think that's bad...").

I'll keep it in mind. The thing that annoys me about the prospect of advancing in management is that I guess at some point you get to deal with The Client hahaha. It's just that the ones I've met are, let's say, difficult and aimless

It's likely you'll deal with clients within your first year. This is why you need good communication skills. A lot of developers argue that you should have mechanical sympathy. I would suggest that sympathy for the client is more important for you personally, and for business outcomes as well.

Sometimes developers forget that they're on the same team as the client. You're not adversaries, you're collaborators.

I am infamous for being a little too honest with clients - "hey, you think that's bad, let me show you this broken shit...". I understand their frustration - I'm just as frustrated, if not more so (reference my latest rant in the "while (true) {" thread). However, there's a line you really shouldn't cross - you want your clients to trust you, and they won't do that if you're constantly badmouthing your own code.

Upside is that I don't get sent to client sites very often anymore (spend 48 hours traveling to and from Tokyo for a whole 8 hours on site, or eight weeks at sea on a drill ship, and your tolerance for travel goes down real quick).

But yeah, depending on where you work and what you're working on, prepare to have to interact with clients early on. They're not bad people (well, most of them aren't). The worst you can say about most of them is that they're just disorganized, or not quite sure what they want. Your job (well, your BA's job) is to help them figure out what they really want, and then deliver on that vision. You won't be 100% successful. Clients will get frustrated. This is normal. We're humans, we screw up a lot, especially in software. How you respond to the situation is what matters (which means not saying, "hey, you think that's bad...").

Lots of variations on this. Most folks (even some IN the industry) don't have a clue how and what a computer does what it does or what it's capable or not capable of. When you're actually talking to a client, you need to learn how to read between the lines to get what they actually need, say that back to them in another way so they understand, and then be able to articulate how to do it better, or how it won't work well that way so that they can understand it. Then you'll have some clients you deal with that say "do it exactly this way, nothing else" and won't listen to you when you try to explain how it won't work. Then you get proper statement of work, specs, etc saying the client actually wants it this way instead of this other way, and make sure the payment schedule is clear. Then when they blow up because it won't work you can point at all the communication and documentation that said "do it this way". May not always help, but it's a great first line of defense. And in general good practice to have all of that documentation anyway. Because you might just be the next person in a couple of years having to maintain that code and by then you'll have forgotten most of it.

Here is something that has some commonality with neuromaster’s last bullet point - which no one has commented on so I will add a big ++

Quote:

Pick a target date retirement fund and max out your savings/contributions while your expenses are low.

These seem boring and not important but years from now you will be glad you did it.

Start a project journal.

In this journal track every project you work on. Some of the information you will know from the start of the project, some will be acquired during the project and some you will pick up later.

Here is a list of information to include to get you started. As the years go by you will probably make adjustments to this list.

Project name

Start and end dates

Company

Client

Principal project members and the project members you were in direct contact with. Make a note of contact information for each.

Technology

Your role in the project

Make a note of anything that was interesting or different about this project. Technology, infrastructure, process, etc. Follow up with a description if this difference helped or hurt the project.

For everything that went wrong in the project make a note what went wrong, why it went wrong and how it was fixed.

After the project is complete make a list of the lessons you learned on this project.

Anytime you hear updated information about the project make a note. For example, 5 years later you could learn that the client is still using the project – make a note of that. If you learn they increased revenue by 50% without adding any staff then make a note of that.

I keep mine in a bound journal at home. That way I can put comments about my coworkers that are less than flattering.

In the short term this could help you see patterns. You will soon see that the some problems get repeated in projects. The sooner you see these patterns the sooner you will not be the one contributing to them.

This will be worth its weight in gold when it comes time to make a resume and cover letter. All of your job experience is noted in detail.

This will be worth its weight in gold-pressed latinum when it comes time for the job interview. Read this journal over and over during any job hunting period. When you are asked open ended questions (and they are all open ended!) you will have the lessons learned, what when wrong and why, and other details fresh in your mind so you provide topical and detailed answers.