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 :)
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.
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.
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.
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.
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.
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.
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 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.
- 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.
"You know that thing you showed me last week? We sold 2 of them. When is it going to be ready?"
Example:
You get a self parking car demo working.
Sales guy sells self driving car based on your parking demo.
- 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.
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.
- 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.
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 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'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 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'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.
The new javascript broke the donation page and we couldn't accept any donations the entire weekend, lost several thousand pounds.
- 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
- 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.
4 seconds after, internal chat window poping with colleague asking "You're working on the server ?"