What part of your first dev job were you least prepared for?

I was not prepared at all for the amount of freedom I was given. They basically say go make me "cool thing x." When I asked, how, with what language, when do you want it? They responded with "up to you... but it will be on hundreds of servers so make sure it's good."

Some might think that it was great to have so much freedom but when you are just starting out it was incredibly scary.

Political nonsense by far is the worst I had to experience - the code, people, etc were great - the political way of "well we need N managers approval, and X Y Z ... which ABC will never approve unless we DEF GHI ...." - taking something we could do in a few hours with full e2e testing, into a three week project of asking management and getting declined numerous, over the simple reason they're "very busy and don't have time to review properly"

The upside though is that it really teaches you how to word your point very shortly, we quickly learned how to take a proposal and shorten it to a few keywords, and some essentially ipsum text, see the example below:

Proposal: In order to help our marketing team get more leads, we need to redesign the call to action system, it needs to be bold, pop, and it needs to work universally on our platform - every page, in-app, and the user should be able to reach it without clicking more than one button/link. As a result of us losing leads, we're losing a possible revenue of $NNNN/month per customer, assuming we can generate only 30% more leads, and convert 15% to customers, that'll bring our running income up from $nnn,nnn per month to ($nnn,#{FACTOR}|$n#{FACTOR}n,#{FACTOR}nn)

Summary of proposal: We're losing a lot of potential money, we need a better onboarding to make us more money.

I didn't always "know best", but I definitely needed to trust my bullshit detector more.

Turns out the things that seemed like a bad idea were indeed a bad idea and there's no hidden good idea behind them.

For me, it was how easy it is to take on too much work. As someone who has not been naturally assertive in the past, who enjoys being busy and is more than happy to help out - I found that over time I had too many people coming to me with questions and work requests.

Until I started not being able to get my job done and stuff started slipping. I learnt the hard way that I needed to start rejecting meetings, telling people to ask others or find information in a document, put a higher value on my own time and put my foot down if my boss asked me to do too much. It has taught me a lot about time management and assertiveness, very valuable soft skills.

My first dev job was at a huge multinational. I was least prepared for ALL THE ((^^%%&^^$^%&(&%%^ MEETINGS.
Some weeks, wound up pulling ridiculous hours not because of the work load, but because nearly every moment of my "business hours" time was spent in some teleconference room while marketing, sales, and tech management blabbed on about things that could have easily been handled via slack, confluence, or email. So there was the morning standup, a day full of meetings, and if I wanted to keep my job, had to take care of the actual work in the evenings.

My current job is much better. I don't even have a phone at my desk. There are still some meetings throughout the week, but manager used to be a dev too, so he's good about shielding the team from ridiculous meetings.

At first it was very cool, lots of freedom on a solo project. Then I got pulled into the main product of the company while maintaining and developing my solo project (each client meeting more and more requests, you know how it goes).

TL;DR: Time management and saying no.

Office politics and a senior developer's attitude were the worst problem. The senior dev was overprotective of "his" code and had the ear of management since he had been at the company a long time. He routinely trashed other devs, deleted changes made by others and did other things that made the working environment toxic. To make things worse, he produced awful code.

How easy it was.

Bear with me. It wasn't easy, in fact parts of it had me stumped, but after having had unrelated jobs for years I took the plunge. I'd always having thought, "I could never do this professionally, it must be so much harder than my hobbyist programming". It wasn't, it was just different.

How hard I'd make it seem to myself.

I made the rookie mistake of thinking the world balanced on my shoulders. Project managers told me that unless "we" fixed "X" by tomorrow, then feature "Y" wouldn't ship and we'd all be in trouble. Even though I should have known better, and that we could never possibly get "X" finished and tested by tomorrow, I'd stay up all night working is spits and spats and worrying in the spaces. Now I've been in the industry for years, I can see newly-minted programmers coming in with the same worries, and I tell them, hey, it's just a product, or just a website. Nobody's going to die if you don't get the menu to work responsively before next week.

Well, the part related to collaboration with Product Owners and Product Managers was definitely a hell. The middle management teams in big companies are really annoying and sometimes I have a feeling that they are doing the best they can to slow the things down (I've spent more time on meetings than writing code)... Besides that, working with outsourcing teams from India was also hell (no offense).

Database encoding!

I started of freelancing, and one of my first regular clients was from Saudi Arabia. His bread and butter was purchasing PHP scripts for Ad scripts and forums and modifying them to work on his market.

The problem was that he needed everything working right-to-left with Arabic script. Making this work in general was a pain, but MySQL encoding issues took it to whole 'nutter level.

First time I did this, it took me 2-3 days to figure it out. But once I figured it out future similar work I was able to do in 2-3 hours. Which is what I love about programming in general - things you learn speed you up by an order of magnitude.

The hardest part to deal with for me is when the customer is not willing or maybe can't afford the actual hours it takes to build a feature properly, and it still has to be done... Which just naws at my perfectionist tendencies, but that's real life.

Yep. If someone implements some sketchy code I ask a million questions until I find the core reason of why they needed that.

Most of the time it was that they didn't know about some simple functionalities or features of the framework we are working or didn't fully read the documentation because they were in a hurry.

How quickly the 'challenging' aspect of working on the same product day in and day out fades. When I started my first job I felt like there was no way I could figure it all out. Then a month later I was bored because it was all so familiar.

Abundance of business logic in the code. I thought the programming job was about writing code, but on my first project I often would be given task like "when A, B and C are true, X processed by Y returns Z, and it should return Z - 5". I would spent the next four hours learning what A, B and C are and what Y does to X, then I would write a few lines of code (which in turn would break another logic, no tests for devs!). Now I understand that this was due to bad architecture, but then I was puzzled.

The process of integrating my changes to the main codebase, and seeing it go live.

Luckily at school, I did have to use GitHub for a couple of collaborative projects, otherwise this would've been infinitely more daunting.

But at school it was pretty much, commit your code and push it to GitHub. Have other teammates sync and we're good. And when it's time to turn it in to teacher, download it as a zip and upload that to the school website.

At my first job, it was really hard to grasp that we had two separate major branches in Git, one that represents our "Live" code, and one that is what we're working on. But then also some other co-workers have separate branches for projects they're working on.
Not sure how common the exact processes are, but at my old job it went something like: make a pull request, have someone review it, then merge it. Some days, a systems engineer would do a build for our test server. So you'd go check things out on the test server, making sure they work. Hopefully they do. Then a few days before the end of our two-week Sprint, the syseng would do a build for our pre-production environment (PPE). Again, go make sure things work fine. Then a few days later, there was a final build, that went on the Production server. And we'd all stay late that night testing everything we could.

The massive span between finishing some tweak, and seeing it go live, was so surprising to me. And all of the very strict rules to not be broken - making sure you don't merge to the wrong branch; making sure your merge doesn't conflict with others, etc.
I was always second-guessing myself, even though my instinct was right, because of how much my coworkers made a point about Not Doing The Bad Thing.