ROUNDTABLES ★ 57 upvotes 2017

Ask HN: What mistakes did you make in your first software engineering job?

Retrospective Overview & Key Insights

Distilled analysis of the business dynamics, operational challenges, and strategic takeaways:

An open Ask HN community consultation from 2017 where @ryanmccullagh convened hundreds of developers and bootstrappers to share real experiences, hard numbers, and tactics.

Core Principles for Independent Builders:
1
Participants share raw revenue figures, churn rates, and stack decisions that corporate PR never publishes.
2
Recurring answers reveal that distribution, not coding skill, is almost universally the rate-limiting step in developer businesses.
3
Practical recommendations on bookkeeping, payment gateways (Stripe vs Paddle), and freelance-to-product transitions.
Community Debate Themes:

Hundreds of active indie hackers contributed case studies, pricing heuristics, and pitfalls to avoid when moonlighting on side projects.

Community Discussions & Critical Reviews

High-signal perspectives, counter-arguments, and peer founder insights debated on Hacker News (47 total discussions):

AN @andreiw Peer Contributor

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

EL @elmarschraml Peer Contributor

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.

SH @sharmi Peer Contributor

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.

MA @MaulingMonkey Peer Contributor

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

SH @shubb Peer Contributor

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.

HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE ★ 57 points
TOTAL DISCUSSIONS 47 comments
TOPICS & TECH STACK: