Ask HN: What mistakes did you make in your first software engineering job?
49 comments
Pretty much the same story but I left the company rather than being let go. I did work crazy hours every day. Had to give back half of my equity when I left but no regrets. I'm working as a freelance developer making lesser than what I made at a full-time job (I work for 4 hrs a day right now) and couldn't be happier.
"A business is just a business and will get rid of you as soon as it can, so you do the same."
I agree wholeheartedly. even nonprofits, etc., tend to be helmed by folks that think purely in terms of financial statements, etc.
in their eyes, you are nothing more than a line item on a spreadsheet. everyone above you on an orgchart effectively has the power to have you ousted. you, of course, have no such reciprocal power over them.
one key takeaway from this observation: don't live paycheck to paycheck -- it's tempting to buy nice stuff with all this money you're suddenly earning... but don't do it. get serious about your finances now. first priority is to save up buffer funds (six months minimum). don't let their power to fire you turn into the power to seriously wreck your life. be proactive in taking care of yourself, you family, and your career.
and as has been said elsewhere, plan to make a jump to a new firm every 2 to 4 years or so, that's the best way to build up your earning potential.
do i sound cynical? hope for the best but plan for the worst.
I agree wholeheartedly. even nonprofits, etc., tend to be helmed by folks that think purely in terms of financial statements, etc.
in their eyes, you are nothing more than a line item on a spreadsheet. everyone above you on an orgchart effectively has the power to have you ousted. you, of course, have no such reciprocal power over them.
one key takeaway from this observation: don't live paycheck to paycheck -- it's tempting to buy nice stuff with all this money you're suddenly earning... but don't do it. get serious about your finances now. first priority is to save up buffer funds (six months minimum). don't let their power to fire you turn into the power to seriously wreck your life. be proactive in taking care of yourself, you family, and your career.
and as has been said elsewhere, plan to make a jump to a new firm every 2 to 4 years or so, that's the best way to build up your earning potential.
do i sound cynical? hope for the best but plan for the worst.
been there done that.
The 4 classic mistakes of programmers in their first "real" job (all made by myself, too, of course):
1) Spending a lot of time building something yourself, where you could have just used an existing library. Example: Writing XML parsing code using the plain DOM in every single DTO class, rather than using a mapper library.
2) Starting a huge refactoring or rewrite of existing code, for no other reason than you think you know better, while being too new to the project to realize where the real problems or reasons lie.
3) Over-engineering. Typically in building a flexible, powerful framework, where a simple hardcoded implementation would have been sufficient. Example: PO asks for a page with statistics about how often X has happened per month. Built a framework for displaying any kind of statistics simply by supplying a where-clause. Was never used for anything but the original request.
4) Giving unrealistic time estimates by assuming the best case for everything. For any kind of complexity in the requirements, there's always something that does not work out as expected, so plan for it. Also, in most cases it's better to give an estimate that is a little longer, but realistically and reliably achievable.
1) Spending a lot of time building something yourself, where you could have just used an existing library. Example: Writing XML parsing code using the plain DOM in every single DTO class, rather than using a mapper library.
2) Starting a huge refactoring or rewrite of existing code, for no other reason than you think you know better, while being too new to the project to realize where the real problems or reasons lie.
3) Over-engineering. Typically in building a flexible, powerful framework, where a simple hardcoded implementation would have been sufficient. Example: PO asks for a page with statistics about how often X has happened per month. Built a framework for displaying any kind of statistics simply by supplying a where-clause. Was never used for anything but the original request.
4) Giving unrealistic time estimates by assuming the best case for everything. For any kind of complexity in the requirements, there's always something that does not work out as expected, so plan for it. Also, in most cases it's better to give an estimate that is a little longer, but realistically and reliably achievable.
Hit 2, 3, and 4 all on my first project. That went down badly.
A project existed, that I thought sucked, for storing customer details, to let techs remotely lookup things like onsite IP addresses and the like, because clients never really set aside time to document.
I thought two weeks to rebuild the frontend in Python... It took 8, and did not a damn thing more or less, was slower, less reliable and fewer techs knew Python.
I thought it was great for having 100% test coverage, but the fact of the matter was it sucked, was overtime, and pretty much a waste of developer resources.
However, it did inspire the maintainer of the better, original version to document his code, and build a test suite, because he could basically rework the one I made.
A project existed, that I thought sucked, for storing customer details, to let techs remotely lookup things like onsite IP addresses and the like, because clients never really set aside time to document.
I thought two weeks to rebuild the frontend in Python... It took 8, and did not a damn thing more or less, was slower, less reliable and fewer techs knew Python.
I thought it was great for having 100% test coverage, but the fact of the matter was it sucked, was overtime, and pretty much a waste of developer resources.
However, it did inspire the maintainer of the better, original version to document his code, and build a test suite, because he could basically rework the one I made.
We built a DBMS from scratch!
Ok, it started before I joined, but the data at our startup was all basically in text files, not unlike a csv. There were data coming from different sources and needed to be merged with existing. We also needed to do some arbitrage between data from multiple sources, so we wrote an always on server which will do all this in memory and dump the data to the files periodically. Unfortunately, the server can sometimes crash and data yet to be dumped was lost. So, next there was a checkpointing system, which will help recover data in case there was a crash. Slowly it grew into a full fledged data management behemoth.
To be fair, this episode happened more than a decade back. The whole team were freshers straight out of college :) And that system had one of the most readable code, I have ever seen.
It finally took a very senior tech person to come poking and find the inefficiencies. He convinced us of the goodness of MySQL and the whole workflow was then rebuilt around it.
This exercise made us appreciate all the more what a DBMS does and wouldn't miss it for the world.
Ok, it started before I joined, but the data at our startup was all basically in text files, not unlike a csv. There were data coming from different sources and needed to be merged with existing. We also needed to do some arbitrage between data from multiple sources, so we wrote an always on server which will do all this in memory and dump the data to the files periodically. Unfortunately, the server can sometimes crash and data yet to be dumped was lost. So, next there was a checkpointing system, which will help recover data in case there was a crash. Slowly it grew into a full fledged data management behemoth.
To be fair, this episode happened more than a decade back. The whole team were freshers straight out of college :) And that system had one of the most readable code, I have ever seen.
It finally took a very senior tech person to come poking and find the inefficiencies. He convinced us of the goodness of MySQL and the whole workflow was then rebuilt around it.
This exercise made us appreciate all the more what a DBMS does and wouldn't miss it for the world.
1) Over promising on project timelines. It's better to under promise and over deliver than to over promise and work yourself into the ground to meet expectations, or worse, lose the respect of your peers by missing your own deadlines.
2) Working myself into the ground. I am human - I should have treated myself like it.
3) Ignoring office politics and putting my head down. Do not let office politicians step on you and bend truths at your expense. Humbly, confidently and respectfully speak your piece with decorum.
2) Working myself into the ground. I am human - I should have treated myself like it.
3) Ignoring office politics and putting my head down. Do not let office politicians step on you and bend truths at your expense. Humbly, confidently and respectfully speak your piece with decorum.
Could you elaborate more on #3?
Absolutely - I guess this is really better broken down into two points:
Sometimes you need to campaign for yourself, sing your own praises and outline your accomplishments. For a humble person, this can be hard. The inclination to let your work speak for itself is strong. Document your successes. Document your worth.
Also, from my experiences, there will always be non technical people that assume they can dictate certain technical decisions. Tread lightly in these situations - you need to make sure that you're speaking your truth and doing your job to the best of your ability while simultaneously managing the egos of the non-technical people who intend on influencing the decisions without the proper knowledge of the decision being made.
Sometimes you need to campaign for yourself, sing your own praises and outline your accomplishments. For a humble person, this can be hard. The inclination to let your work speak for itself is strong. Document your successes. Document your worth.
Also, from my experiences, there will always be non technical people that assume they can dictate certain technical decisions. Tread lightly in these situations - you need to make sure that you're speaking your truth and doing your job to the best of your ability while simultaneously managing the egos of the non-technical people who intend on influencing the decisions without the proper knowledge of the decision being made.
[deleted]
My major mistake was taking a job that I doing stuff I didn't care about because it was a good career move.
I learned that I need to care what I'm building (self actualize), and if I don't then work feels like selling my life a day at a time. It was though a good thing to learn.
I also didn't realize that I was inexperienced. That meant I held myself to the same standards as much more knowledgeable people and worried about my performance (which was normal for a decent fresh grad). At the same time, I didn't use more senior staff to guide me on hard decisions or shield me from management, which was unnecessarily stressful.
The other big issue was sleep and generally learning to live as a working person. I needed to figure out how to eat well and cheaply. I also needed to go to bed way earlier than I did an got very tired over a couple of years. Just because at 20 you can stay up till 2am every night and still get up at 7 doesn't mean you should. Don't.
I learned that I need to care what I'm building (self actualize), and if I don't then work feels like selling my life a day at a time. It was though a good thing to learn.
I also didn't realize that I was inexperienced. That meant I held myself to the same standards as much more knowledgeable people and worried about my performance (which was normal for a decent fresh grad). At the same time, I didn't use more senior staff to guide me on hard decisions or shield me from management, which was unnecessarily stressful.
The other big issue was sleep and generally learning to live as a working person. I needed to figure out how to eat well and cheaply. I also needed to go to bed way earlier than I did an got very tired over a couple of years. Just because at 20 you can stay up till 2am every night and still get up at 7 doesn't mean you should. Don't.
I feel as though I am falling into this right now. I graduated in Spring of 2016, and started working full time a week after that.
I started working for the same boss that I interned at (different company) - and it has been awesome thus far.
Although the subject matter of the stuff I work on it pretty boring I still have fun with what I do. It's pretty crazy how much experience you gain from just doing your job.
I still don't get a ton of sleep and I generally fall into what you described above.
I started working for the same boss that I interned at (different company) - and it has been awesome thus far.
Although the subject matter of the stuff I work on it pretty boring I still have fun with what I do. It's pretty crazy how much experience you gain from just doing your job.
I still don't get a ton of sleep and I generally fall into what you described above.
- Going with the gut instead of listening to others. I had the surrealistic experience of a bunch of extremely senior folks around a company telling me not to join a team I had done a project for. I should have listened, esp. in light of the fact that the folks advising were not only not from the same team, but in many cases actively disliked each other (i.e. this was not a conspiracy).
- Ignoring the office politics. I thought, naively, that doing above and beyond technically and being frank about situations around me would get me somewhere. It turned out that someone I had put in a not-so-favorable crosshair, while describing my fairly significant cross-team collab efforts, was chummy with my manager's manager, and it blew up in my face... see next item...
- I had the misfortune of deciding to report to an average-engineer-turned-mediocre-manager. Typical deer-in-headlights-look turnstile manager - i.e. the kind that takes plenty of credit, but doesn't shield you from anything. The guy was laughably terrible, because it was extremely obvious when he was trying to screw you in 1:1s. I was young and stupid and it ended pretty nasty: vindicative passive-agressive bullshit, blame game and damaging rumors that impacted my professional relationship with the rest of my ex-teammates.
- Not setting priorities straight. I had a personal situation that involved a lot of travel. It didn't even matter that I was exceeding expectations - visibly, I was never there, and that is all that ultimately mattered.
But these are all symptoms! The biggest mistake was not identifying a mentor. Not a technical mentor, but someone seasoned, high enough in the social ranking, and vibrant enough (i.e. not semi-retired and clinging to the job) to advise, help and teach how to navigate a large megacorp with its feudal cliques, ol' boy's club politics and Machiavellian egoes.
- Ignoring the office politics. I thought, naively, that doing above and beyond technically and being frank about situations around me would get me somewhere. It turned out that someone I had put in a not-so-favorable crosshair, while describing my fairly significant cross-team collab efforts, was chummy with my manager's manager, and it blew up in my face... see next item...
- I had the misfortune of deciding to report to an average-engineer-turned-mediocre-manager. Typical deer-in-headlights-look turnstile manager - i.e. the kind that takes plenty of credit, but doesn't shield you from anything. The guy was laughably terrible, because it was extremely obvious when he was trying to screw you in 1:1s. I was young and stupid and it ended pretty nasty: vindicative passive-agressive bullshit, blame game and damaging rumors that impacted my professional relationship with the rest of my ex-teammates.
- Not setting priorities straight. I had a personal situation that involved a lot of travel. It didn't even matter that I was exceeding expectations - visibly, I was never there, and that is all that ultimately mattered.
But these are all symptoms! The biggest mistake was not identifying a mentor. Not a technical mentor, but someone seasoned, high enough in the social ranking, and vibrant enough (i.e. not semi-retired and clinging to the job) to advise, help and teach how to navigate a large megacorp with its feudal cliques, ol' boy's club politics and Machiavellian egoes.
Letting the sales guys see what you're working on/playing with especially when it's not necessarily going to be part of the product.
"You know that thing you showed me last week? We sold 2 of them. When is it going to be ready?"
"You know that thing you showed me last week? We sold 2 of them. When is it going to be ready?"
Can you elaborate on that?
Often as a developer, you might work on some experimental projects that may not pan out. That's why you try them. They may work for 80% of the use cases but not for the rest and thus aren't workable from a product standpoint. The sales guys however, may see the "working" project and go out and sell it without asking if it's a product.
Example:
You get a self parking car demo working.
Sales guy sells self driving car based on your parking demo.
Example:
You get a self parking car demo working.
Sales guy sells self driving car based on your parking demo.
- Mimicking the existing coding style a bit too closely - including some of the mistakes which made some stuff brittle, despite having some reservations about it.
- Kicked off a major refactoring which I wasn't able to secure time to finish, leaving behind partially refactored code. Would've been better to break it up into several smaller refactorings, instead of having the codebase straddling two different styles of doing the same stuff.
- Not reaching out to the rest of my coworkers aggressively enough. I annoyed my lead a bit by asking him all my questions at the beginning.
- Not pushing back heavily enough on code readability in reviews, leading to a couple of mudballs (generally under a KLOC fortunately, but still hard to figure out in a couple cases.)
- Crunching, firefighting, and not taking care of myself better.
I also didn't start with any real experience with project management, time estimation, or the art of managing expectations and keeping managers in the loop - although I managed to learn quickly enough to stay out of trouble, for the most part.
- Kicked off a major refactoring which I wasn't able to secure time to finish, leaving behind partially refactored code. Would've been better to break it up into several smaller refactorings, instead of having the codebase straddling two different styles of doing the same stuff.
- Not reaching out to the rest of my coworkers aggressively enough. I annoyed my lead a bit by asking him all my questions at the beginning.
- Not pushing back heavily enough on code readability in reviews, leading to a couple of mudballs (generally under a KLOC fortunately, but still hard to figure out in a couple cases.)
- Crunching, firefighting, and not taking care of myself better.
I also didn't start with any real experience with project management, time estimation, or the art of managing expectations and keeping managers in the loop - although I managed to learn quickly enough to stay out of trouble, for the most part.
Don't upgrade MYSQL on production without backups! Fortunately I was able to pull the database files into a old version and export them, but that was a really tense conversation with my boss.
Thinking back on it, they put a LOT of trust in me at 16. I was the only web dev at a small GIS shop for a summer. They hired me on to rebuild their PHP websites. I didn't know PHP at the beginning of the summer.
Thinking back on it, they put a LOT of trust in me at 16. I was the only web dev at a small GIS shop for a summer. They hired me on to rebuild their PHP websites. I didn't know PHP at the beginning of the summer.
Yeah, sounds like that wouldn't have been your fault if it had become a worse problem. Reminds me of that story I saw on HN a few years ago where the guy dropped a table of user details (by accidentally clicking on the wrong thing I think) on a live DB server for an online game and there were no backups. They had to re-enter the users' details based on what each user claimed they had in their account; it was a real mess and arguably not the person's fault.
These threads area always fun. I'll give my "eng/arch/social" bad-decision-eigenvectors.
- Deleted /etc on a live cluster, due to interpolation in a CMS script which tried to pretend that solaris wasn't a thing.
- Overengineered _everything_ as opposed to recognizing that 90% of the time the needs really demanded something that would just work and people could forget about.
- Let myself identify too much with my work. I made choices in work life balance and in letting myself feel shitty about things out of my control that you can't let bother you if you're going to keep smiling and moving forward.
- Deleted /etc on a live cluster, due to interpolation in a CMS script which tried to pretend that solaris wasn't a thing.
- Overengineered _everything_ as opposed to recognizing that 90% of the time the needs really demanded something that would just work and people could forget about.
- Let myself identify too much with my work. I made choices in work life balance and in letting myself feel shitty about things out of my control that you can't let bother you if you're going to keep smiling and moving forward.
Accidentally released a version that contained a Thread.sleep(1000); call in the frame-saving loop of the video recording feature. We had put it in to simulate a slow hard drive so we could watch how the system reacted. It reacted quite well until it ran out of ram.
I refactored the User.rb file of a massive, legacy Rails app with that classic save-the-world beginner hubris.
For one, I thought I was helping out by alphabetizing all the methods.
Ended up with a diff that basically scrambled all 100k lines of the project's largest file. It's probably still causing merge conflicts to this day.
For one, I thought I was helping out by alphabetizing all the methods.
Ended up with a diff that basically scrambled all 100k lines of the project's largest file. It's probably still causing merge conflicts to this day.
I didn't push back enough on stories that were poorly thought out.
I didn't ask enough questions and make sure I understood the real problems before trying to write code.
I wasted a bunch of time trying to get a jenkins server running when I had no real ops experience, and a SaaS CI would have been much better.
I didn't communicate the problems I was having, or ask for help. I was really accomplished in school, where everything came easy to me, so I got flustered when I couldn't figure out the solution on my own.
I didn't ask enough questions and make sure I understood the real problems before trying to write code.
I wasted a bunch of time trying to get a jenkins server running when I had no real ops experience, and a SaaS CI would have been much better.
I didn't communicate the problems I was having, or ask for help. I was really accomplished in school, where everything came easy to me, so I got flustered when I couldn't figure out the solution on my own.
Did the exact same things.
- Overengineering. Developed a cool abstract and highly configurable three-tier monster when all was needed was a good lookin' excel sheet. Very useful humbling experience. The boss knew I was all wrong but let me hit the wall so that I learn my lesson. I did! Ouch!
I wrote some software in a language I didn't really know, didn't test it well enough, and when broke it completely disabled the service we were providing to the company's largest customer. Luckily it only crashed at 4AM every night, instead of during main use hours, but it was still no good.
I'm actually writing a newsletter of mistakes I've made over 20 years of working as a programmer; I've made quite a few! That's just the first of the mistakes you could be avoiding (they're written up in much more detail, of course): https://softwareclown.com
I'm actually writing a newsletter of mistakes I've made over 20 years of working as a programmer; I've made quite a few! That's just the first of the mistakes you could be avoiding (they're written up in much more detail, of course): https://softwareclown.com
I don't understand. Why not just post the content in your blog instead of forcing you to subscribe to the newsletter. That's awful.
I see this guy post a link to his newsletter almost daily :/
I tried to read some of them - but as you had mentioned you have to subscribe. I'm assuming he gets a kickback of some sort for a subscription.
I tried to read some of them - but as you had mentioned you have to subscribe. I'm assuming he gets a kickback of some sort for a subscription.
No kickbacks for subscriptions. Eventually I'd like to have them up on a page too, but mostly I want newsletter format, and current email software doesn't let me easily put up emails on the web. And I don't have time to do it manually.
Ah no worries I didn't mean to assume :)
I'm interested in reading, but most of the newsletters I have signed up for stopped sending - I'd be fine with an RSS sort of setup as well.
I'm interested in reading, but most of the newsletters I have signed up for stopped sending - I'd be fine with an RSS sort of setup as well.
When you sign up you start at the beginning, so if I stop posting tomorrow at a minimum you'll have... 23 weeks of content. And I do plan to keep posting, although eventually I'll run out of interesting mistakes and will need to tweak the format.
I can understand why it's a newsletter rather than a blog. Receiving weekly emails would keep reminding people of new content so they wouldn't have to remember to check the blog.
Using floats to represent monetary values. It "works" 99.9% of the time, until it doesn't. Dammit, Flex.
My only true mistakes were people mistakes: Being too cocky. Underestimating the capabilities of my seniors. Competing with my co-workers rather than cooperating. Not learning to communicate effectively.
I was put on a project to implement payment processing with the UnionPay API. I had documentation in Chinese, of which I knew 15 words. I didn't insist on professional translation, but tried to make do with google translate. Failing to understand the errors I was getting, I continued just trying things and banging my head against the wall.
Had to deploy our new design by Friday, wasn't enough time. Deployed Friday afternoon before leaving for the weekend.
The new javascript broke the donation page and we couldn't accept any donations the entire weekend, lost several thousand pounds.
The new javascript broke the donation page and we couldn't accept any donations the entire weekend, lost several thousand pounds.
My work has an unwritten rule about never deploying on a Friday... I had to learn the hard way!
"killall" on Solaris is very different to "killall" on Linux.
Not investing in refactoring until it was way too late. When you do not have a lot of experience yet, it is hard sometimes to get budget for something that does not bear visible fruit immediately, like refactoring.
I am currently at my first software engineering job, and a few mistakes already:
- Debugging before thinking enough on the subject
- Over-engineering even the simplest things
- Expecting normal people (ie. support team) to know know about tree/graph structures
- Debugging before thinking enough on the subject
- Over-engineering even the simplest things
- Expecting normal people (ie. support team) to know know about tree/graph structures
[deleted]
Wrote a static code generator that used a database schema as input. (this was a big design up front project, and other generators existed at the time the company did not want to purchase)
- Did not educate myself about market rate for my position.
- Did not negotiate compensation.
- Over-identified with my work.
- Trusted employer to match my level of selflessness.
- Underreported hours worked.
- Did not limit the number of hours worked in a week.
- Did not negotiate compensation.
- Over-identified with my work.
- Trusted employer to match my level of selflessness.
- Underreported hours worked.
- Did not limit the number of hours worked in a week.
"rm -rf server" instead of "rm -rf server.bak"
4 seconds after, internal chat window poping with colleague asking "You're working on the server ?"
4 seconds after, internal chat window poping with colleague asking "You're working on the server ?"
Allowing myself to be bullied and voluntold to do things.
Believing the hype about stock options.
I actually felt like I was part of the team and making the product a reality. I was a founding engineer, employee #1. I out lasted every other founding member including the co-founder. I ended up picking up his slack.
Four years and lots of revenue later I was let go. Apparently I "outgrew" the team, what the fuck ever that means. Lesson learned, think of yourself first. A business is just a business and will get rid of you as soon as it can, so you do the same.
My second mistake was working too much. I didn't value my own time and should have spent more time with my family instead of slaving away for someone else's idea. Lesson learned, put you and those important to you first. A job is just a job, a company is just a company. None of that is worth losing time with people that actually matter.
My third mistake? I didn't make any more :)