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.
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).
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).
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.
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.
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.
When I'm programming, I have the habit to talk with myself (think out loud) and my colleagues hate it. I guess ideas come so slowly when I try to not to do it (or sometimes they simply don't come). When I finish my college, this is the thing which worries me more when I finally start to work. And, according to one of my teachers, I'm a so "intempestive" person and have to improve it too.
Straight out of college, I had a tough time starting to collaborate with other developers, who were also competing with me in the company for recognition of their work.
Colleges do not prepare for real world work environment.
My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
Customer relations. I was 20, first job ever, somewhat knew how to program professionally, and I was sent alongside my tech lead at the client's office to handle a new project.
Was incredibly fun and I gained a lot of experience, but it was terrifying and I was absolutely not ready for it
It took me ten years to get my first dev job (previously I was in Ops/SysAdmin role).
I had done OOP at University, but at the time the Gang of Four and Design Pattern didn't exist. Also I would say that I was more of a procedural based programmer (Pascal, C, COBOL and Assembly).
So fast forwards to my first dev job, I found myself struggling with concepts that peers took for granted. Nearly all my code looked more like procedural, rather than the message passing.
If I could do it all again, I would've asked my manager to send me on an OOP course rather than a .NET course which left me even more confused.
1: Pull request feedback - in my job we peer review all pull request's for our team and I was not prepared for the kind of feedback I would get. Accepting feedback on something you made in code is learned for me and I was not used to other people looking at my code like this.
2: How strongly people feel about code formatting - I never thought that I'd see so many people so passionate about the placement of a bracket.
3: Assuming that everyone around me and people who were more experienced than I was knew everything about a given subject. Its important to take in information given to you by a superior or a seasoned developer but as long as you research that information to learn more about it.
I feel like all of my points here are just signs that I needed to grow up at some point in my career! But really that's what I wasn't ready for. I knew I would work long hours and I was ready for that. It's all the items above that I didn't expect.
From memory this was having to write tests for all the code I wrote.
The subject of automated/unit tests never came up when I was a student, so not only was it a surprise but seemed like a real chore because in many cases writing the tests took longer than making the code change.
As a new developer, college never prepared me for the entire SDLC or how to work with others. It instilled a constant feeling of competition within me. Professional work is almost always a collaboration and is almost never a competition within the same product or service.
Having more technical knowledge/experience and being more results-driven than my manager. I bowed my head and did a lot of silly work. I likely would have enjoyed the job much more if I had spoken up about some of the tasks.
Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
Professionalism- working for an older company, I was not prepared for all the fake-ness that was asked of me. Essentially being someone I’m not. Needless to say I wasn’t happy at that company.
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 want to type of freedom......
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 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.
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.
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.
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.
When I'm programming, I have the habit to talk with myself (think out loud) and my colleagues hate it. I guess ideas come so slowly when I try to not to do it (or sometimes they simply don't come). When I finish my college, this is the thing which worries me more when I finally start to work. And, according to one of my teachers, I'm a so "intempestive" person and have to improve it too.
Straight out of college, I had a tough time starting to collaborate with other developers, who were also competing with me in the company for recognition of their work.
Colleges do not prepare for real world work environment.
Customer relations. I was 20, first job ever, somewhat knew how to program professionally, and I was sent alongside my tech lead at the client's office to handle a new project.
Was incredibly fun and I gained a lot of experience, but it was terrifying and I was absolutely not ready for it
It took me ten years to get my first dev job (previously I was in Ops/SysAdmin role).
I had done OOP at University, but at the time the Gang of Four and Design Pattern didn't exist. Also I would say that I was more of a procedural based programmer (Pascal, C, COBOL and Assembly).
So fast forwards to my first dev job, I found myself struggling with concepts that peers took for granted. Nearly all my code looked more like procedural, rather than the message passing.
If I could do it all again, I would've asked my manager to send me on an OOP course rather than a .NET course which left me even more confused.
A few things
1: Pull request feedback - in my job we peer review all pull request's for our team and I was not prepared for the kind of feedback I would get. Accepting feedback on something you made in code is learned for me and I was not used to other people looking at my code like this.
2: How strongly people feel about code formatting - I never thought that I'd see so many people so passionate about the placement of a bracket.
3: Assuming that everyone around me and people who were more experienced than I was knew everything about a given subject. Its important to take in information given to you by a superior or a seasoned developer but as long as you research that information to learn more about it.
I feel like all of my points here are just signs that I needed to grow up at some point in my career! But really that's what I wasn't ready for. I knew I would work long hours and I was ready for that. It's all the items above that I didn't expect.
From memory this was having to write tests for all the code I wrote.
The subject of automated/unit tests never came up when I was a student, so not only was it a surprise but seemed like a real chore because in many cases writing the tests took longer than making the code change.
As a new developer, college never prepared me for the entire SDLC or how to work with others. It instilled a constant feeling of competition within me. Professional work is almost always a collaboration and is almost never a competition within the same product or service.
The coding. I had no clue what I was doing!
Having more technical knowledge/experience and being more results-driven than my manager. I bowed my head and did a lot of silly work. I likely would have enjoyed the job much more if I had spoken up about some of the tasks.
I would have to say the politics and power differentials.
Professionalism- working for an older company, I was not prepared for all the fake-ness that was asked of me. Essentially being someone I’m not. Needless to say I wasn’t happy at that company.
The expectations and being asked how long something I'd never done before was going to take (and being expected to know right off).
Introducing change without previous experience as a developer.
I learned that Git, SASS and Gulp were good tools.
But my friend developer was too reluctant to event consider them.
Business process.
Dealing with people and saying no sometimes