4 ms·

I think it's worth thinking about why you were successful as a freelancer and in smaller companies. I started my career in a simmilar place, and I was very succ

I think it's worth thinking about why you were successful as a freelancer and in smaller companies. I started my career in a simmilar place, and I was very successful because I loved learning about the business, talking to stakeholders and delivering value. The code wasn't always great, or even good, but it was delivered quickly and users found it solved genuine problems. When I transitioned into larger "software" companies I found I was often surrounded by people who were focused on ideological purity, but insulated from the impacts of their changes. They would spent 6 months polishing something that nobody used, or replacing a perfectly good system with a rewrite that had half as many features. I simultaneously felt like I wasn't good at writing software, and that the problems I was working on didn't matter, which is a pretty kiler combo and burns you out very quickly. My advice is: emphasize how you deliver value, how you're flexible, pick things up quickly, understand the business, etc. Freelancing is more impressive to me when I'm hiring than career big-co developers, because you can't fuck around. If you're not delivering value you're gone. Structuring code well and making it easy to debug is something you'll learn as you work on more, larger systems. It's a muscle you can practice, and you can be up front that it's something you want to improve on. I absolutely think it's something you'll improve on when you're at a company, it's hard to learn on your own.

dntrkv 6y ago
> I think it's worth thinking about why you were successful as a freelancer and in smaller companies. Assuming they were successful. I cringe thinking about the devs that inherited my code in my early days as a "dev" (using that term very loosely). Especially the freelance work, since in many cases you're the only that touches it until you move on. Then it's some other devs problem. The idea that just because your code solved the problem then it's good enough is bullshit, especially if you're not the one that has to maintain your monstrosity of a codebase going forward. I know many projects that I built in my earlier years were rewritten right after I left. The embarrassment I felt from that motivated me to learn to do things the right way.
- jsjsbdkj 6y ago
  > The idea that just because your code solved the problem then it's good enough is bullshit, especially if you're not the one that has to maintain your monstrosity of a codebase going forward. It's a lot better than beautiful code that _doesn't_ solve the problem. If I had to choose between them, I'd rather rewrite something that's wildly successful than try and make an unpopular piece of software popular. OP can learn how to write more maintainable software, but it sounds like they already have a good instinct for making useful software that people actually want. IMO that's rarer and more valuable.

dntrkv 6y ago

> I think it's worth thinking about why you were successful as a freelancer and in smaller companies. Assuming they were successful. I cringe thinking about the devs that inherited my code in my early days as a "dev" (using that term very loosely). Especially the freelance work, since in many cases you're the only that touches it until you move on. Then it's some other devs problem. The idea that just because your code solved the problem then it's good enough is bullshit, especially if you're not the one that has to maintain your monstrosity of a codebase going forward. I know many projects that I built in my earlier years were rewritten right after I left. The embarrassment I felt from that motivated me to learn to do things the right way.

jsjsbdkj 6y ago
> The idea that just because your code solved the problem then it's good enough is bullshit, especially if you're not the one that has to maintain your monstrosity of a codebase going forward. It's a lot better than beautiful code that _doesn't_ solve the problem. If I had to choose between them, I'd rather rewrite something that's wildly successful than try and make an unpopular piece of software popular. OP can learn how to write more maintainable software, but it sounds like they already have a good instinct for making useful software that people actually want. IMO that's rarer and more valuable.