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.
This is going to sound bad, but coming right out of liberal arts academia, I was genuinely shocked at how the business world values bullet-points and slideshows more than well-written, in-depth explanations.
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.
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.
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
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).
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.
Meeting culture in large organizations continues to perplex me. I can't wrap my head around how people think that detaining folks from their core responsibilities is the most productive use of time. My biggest pet peeve is the "just dial in and do your work until they have a question for you." If I am not an integral part of the conversation then let me do my job in peace and slack me your questions. Shesh.
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.
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
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.
Oldest comments (38)
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.
This is going to sound bad, but coming right out of liberal arts academia, I was genuinely shocked at how the business world values bullet-points and slideshows more than well-written, in-depth explanations.
This is interesting to know. I didn’t come from a solely liberal arts background but I like well-written, in depth explanations
Vouch for this. The executive summary, as these bullet points are called, precede all explanation and many-a-times, substitute the explanation.
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 coding. I had no clue what I was doing!
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.
I would ask the devs that are more experienced with the project if I think I am doing something wrong
I also felt I was offered a bit too much freedom. Not as much as you but enough to not really know what I should be doing!
I want to type of freedom......
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).
I would have to say the politics and power differentials.
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.
Meeting culture in large organizations continues to perplex me. I can't wrap my head around how people think that detaining folks from their core responsibilities is the most productive use of time. My biggest pet peeve is the "just dial in and do your work until they have a question for you." If I am not an integral part of the conversation then let me do my job in peace and slack me your questions. Shesh.
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.
Our client is a feature freak and they keep asking for features all the time even though our project was at an all times low in terms of code quality.
I learned how to pair functionalities with refactoring from this and things are working out very well.
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.
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.