291–300 of 348 posts
Option piece is misleading. You own 1% of options and company is bought for $10m. Your payoff? Likely $0. He forgot to mention preferred shares given to VC’s with liquidation preferences that likely never disclosed to new engineers. This is what makes new engineer to sacrifice his salary for a possible liquidation even that likely either never happens or there is no money left for him after VCs took their xN ratios o…
Earlier quoted context omitted.
For the first year or so, the only way to get builds of our software was for me to click "build" in Visual Studio, on my laptop. I definitely knew how to set up a build server, CI pipeline, etc. It just would have meant that every time I (not we!) changed the build, I would have to fix my own machine and the pipeline. I'd much rather spend that time fixing one more issue, or adding one more feature. There are numerou…
If your CI breaks every time you change the build you are doing something wrong.
Earlier quoted context omitted.
If you need to worry that much about the rent payment as a software engineer in current times you either lack skill (in interviewing or on job) or sold yourself way under worth.
There's a ton of circumstances that could put even a software engineer into financial trouble. Don't assume that a software engineer automatically equals a high savings.
Earlier quoted context omitted.
> If you want your startup to run for more than a year I've never seen a start-up fail on account of technical debt. Re-engineering is expensive, but it means you have something worth re-engineering. I've seen lots of start-ups fail because money that should have been spent attracting and retaining users got burned on an elaborate engineering process.
> I've never seen a start-up fail on account of technical debt. That's because noone ever says "XYZ startup failed because their code quality wasn't good enough." It's usually something closer to "Their customers didn't renew contracts, they had to slash headcount, and went into a death spiral from there." If you press for details, the deeper reason might be "they couldn't turn around features fast enough" or "the ap…
Poor code quality is rarely perceivable by customers, except in the most extreme cases.
Get. It. In. Writing. I will say this much. People have bad memories. That includes you. You think you remember that conversation perfectly? You probably don't. Get. It. In. Writing. And don't trust anyone who won't commit to writing.
Or just go work for a more established company where you don't have to deal with this stuff. Because, frankly, you're not ready for a startup if you don't have the mental intuition to ask for everything in writing.
Major Omission: People Ask yourself- Do I trust the founders? Can I have healthy debate with the founders? Will my feedback be considered by the founders? Am I compatible with the founders? Are the founders compatible with each other and are they able to work together constructively?
> Do I trust the founders?
At first, I did because I was too green about small businesses. I thought the worst they could do was pay me lower wages. Oh, boy, was I wrong. Not only did I get 1099'd, but also had my hours and wages cut two months in. (The 1099 was resolved, though, thanks to the IRS's contest process.)
> Can I have healthy debate with the founders?
I found out after joining that the founders were married. So no to this one.
> Will my feedback be considered by the founders?
It was, but then promptly discarded since the founders lied about their technical skills (they knew enough to sell tech but not to build it). So everything was a game of "why can't you just drag/drop this X thing like we can in Photoshop".
> Am I compatible with the founders?
One of the founders sold me on the fact that he played guitar. But then I found out that they blasted the office with very light AM classical music for the whole day. So nope, not compatible.
> Are the founders compatible with each other?
They were married, so no.
> Are they able to work together constructively?
See the above comment.
------
Anyways, my experience is only anecdotal. But yeah, really dive into the founder's dynamics to see if you can tolerate them or not before accepting a job.
Earlier quoted context omitted.
I disagree - tech debt and bad practices can be fixed with good leadership. But poor leadership will never give you the opportunities to make such corrections. I do agree that knowing the status quo is useful, but the trajectory the organization is on is more important than today's exact position. I ask questions more along the lines of what is wrong, and how are they correcting it. Good answers there can show a good…
Isn't it a matter of ones preferences though? Even if the leadership is capable if a person finds day to day work with crappy codebase and poor tooling a drag there is no point in joining.
I wonder if it's simply the balls to tell top management that we need to invest in training, refactoring etc. And selling it that it will payoff.
The usual answer I get when I propose this, is that "we're too busy with projects".
There are no engineering questions on this list, and the more I think about it, the more correct I think that is. Unless you're stretching the definition of a startup, most of what passes for current engineering is volatile and subject to lots of change. Better to ask questions about the team and their experience so you know what you'll need to build.
Earlier quoted context omitted.
I would expect most to be disappointing too, and it's a good idea to avoid those. Proper logging doesn't take more time, it just takes more discipline / giving a damn. People and companies that say: we don't have time to do it right Almost always mean: we don't know how to do it right Talent, not time, is the enemy of quality. (at some point that stops being true, but most companies (startups or not) are soooo far fr…
For the first year or so, the only way to get builds of our software was for me to click "build" in Visual Studio, on my laptop. I definitely knew how to set up a build server, CI pipeline, etc. It just would have meant that every time I (not we!) changed the build, I would have to fix my own machine and the pipeline. I'd much rather spend that time fixing one more issue, or adding one more feature. There are numerou…