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.
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.
A keen problem solver, whether it's related to people, processes or tools. Currently being excited by integration - the whole is more than the sum of its parts, particularly in a complex system.
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.
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.
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.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
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).
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.
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.
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.
Top comments (38)
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 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......
I would ask the devs that are more experienced with the project if I think I am doing something wrong
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.
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.
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.
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).
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.
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.