Ask HN: What mistakes did you make in your first software engineering job? - ryanmccullagh
======
lilbobbytables1
My first mistake was believing in the founder and his vision.

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 :)

~~~
keviv
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.

------
elmarschraml
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.

~~~
shakna
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.

------
sharmi
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.

------
ryantmusser
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.

~~~
BOOSTERHIDROGEN
Could you elaborate more on #3?

~~~
ryantmusser
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.

------
shubb
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.

~~~
kzisme
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.

------
andreiw
\- 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.

------
chrisbennet
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?"

~~~
niyikiza
Can you elaborate on that?

~~~
chrisbennet
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.

------
MaulingMonkey
\- 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.

------
revx
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.

~~~
dasboth
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.

------
existencebox
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.

------
daze42
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.

------
danneu
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.

------
jmcgough
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.

~~~
bradyo
Did the exact same things.

------
crocal
\- 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!

------
itamarst
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](https://softwareclown.com)

~~~
spdionis
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.

~~~
kzisme
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.

~~~
itamarst
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.

~~~
kzisme
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.

~~~
itamarst
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.

~~~
trendia
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.

------
ap22213
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.

------
afarrell
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.

------
theandrewbailey
Using floats to represent monetary values. It "works" 99.9% of the time, until
it doesn't. Dammit, Flex.

------
gaius
Believing the hype about stock options.

------
sharps_xp
Ran rake db:drop and no, it was not on my local machine.

~~~
ketpat
My god! Just reading this gave me the shivers.

------
ketpat
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.

~~~
thatguyhughesy
My work has an unwritten rule about never deploying on a Friday... I had to
learn the hard way!

------
pjc50
"killall" on Solaris is very different to "killall" on Linux.

------
tluyben2
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.

------
yigitozkavci
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

------
noshbrinken
\- 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.

------
aaronhoffman
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)

------
mirages
"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 ?"

------
probinso
Allowing myself to be bullied and voluntold to do things.

