3 ms·

Part of the difficulty is navigating two sets of incentives. While yes, you can write fast and loose code that only a mother would love and do plenty of things

by asdff 3y ago

Part of the difficulty is navigating two sets of incentives. While yes, you can write fast and loose code that only a mother would love and do plenty of things much faster than whatever way is perfectly orthodox and correct. However, to be competitive in the job hunt, its expected people to have this portfolio of clean model code that follows all the best practices. The startup could fire you at any time, and you better have hoped you did your due diligence to spend part of your time on your own marketability instead of devoting it all to the startup, in this all too likely situation.

mrfox321 3y ago
I think you overestimate the likelihood of being judged on code in GitHub.
vegetablepotpie 3y ago
I believe the term for this is resume driven development. This also leads developers to focus on learning new technologies and integrating them to their current project, whereas what the business really needs are stable boring solutions. Of course if developers do focus exclusively on serving the needs of the business, they’re not building up their skills for their next job, and the business could still fail for circumstances outside of their control. There’s a software law called Teslers law [1], which says that complexity cannot be eliminated, the most that can be done is to shift it from one part of the system to the next. You can make a similar law about risk. As a developer, if I ship a build system (complete a project successfully), or I build something with a new technology, I have a point to put on a resume and a successful accomplishment to talk about in my next interview. It may be that this is the wrong move for the business. It may be that they need a crappy spaghetti code abomination to achieve a product market fit in that time. If founders know what’s going on and they stipulate boring solutions the developer accepted risk. They’ve completely invested in the business and are completely tied to the decisions of their founders and leadership for their success. In a perfect world this would start a conversation about compensation for accepting or balancing risk, but in my experience this absolutely never happens because it gets political. Leaders always win because they’re better politicians than developers. It’s easy for leaders to be willfully ignorant and dismiss these concepts as too detail oriented, and devolves into leaders saying “we’re nice people, trust us”. But the risk is there and someone is accepting it and developers respond to this by mitigating it on their end deep in the implementation details. We have optimized at a local maximum, but are globally suboptimal. I do not believe we’ll ever achieve something more optimal because in business climates, everyone is trying to get something for very little effort. It takes much time to earn trust, but very little time to destroy it. [1] https://en.m.wikipedia.org/wiki/Law_of_conservation_of_complexity https://en.m.wikipedia.org/wiki/Law_of_conservation_of_compl...
- astrange 3y ago
  > I believe the term for this is resume driven development. This also leads developers to focus on learning new technologies and integrating them to their current project, whereas what the business really needs are stable boring solutions. This can also help recruiting; that's why Uber had all those technical blogs about how super-complicated and full of Scala their solutions were, when Uber's business could be run on a PC under a desk. Also why Palantir is called Palantir. They don't actually do anything cool or spy on people, but the name is intended to help get young tech people to work on boring government work without having to pay them more.
civilized 3y ago
What portfolio? Unless you're open sourcing or squirreling away your company's code via email.

by asdff 3y ago

mrfox321 3y ago

I think you overestimate the likelihood of being judged on code in GitHub.

vegetablepotpie 3y ago

I believe the term for this is resume driven development. This also leads developers to focus on learning new technologies and integrating them to their current project, whereas what the business really needs are stable boring solutions. Of course if developers do focus exclusively on serving the needs of the business, they’re not building up their skills for their next job, and the business could still fail for circumstances outside of their control. There’s a software law called Teslers law [1], which says that complexity cannot be eliminated, the most that can be done is to shift it from one part of the system to the next. You can make a similar law about risk. As a developer, if I ship a build system (complete a project successfully), or I build something with a new technology, I have a point to put on a resume and a successful accomplishment to talk about in my next interview. It may be that this is the wrong move for the business. It may be that they need a crappy spaghetti code abomination to achieve a product market fit in that time. If founders know what’s going on and they stipulate boring solutions the developer accepted risk. They’ve completely invested in the business and are completely tied to the decisions of their founders and leadership for their success. In a perfect world this would start a conversation about compensation for accepting or balancing risk, but in my experience this absolutely never happens because it gets political. Leaders always win because they’re better politicians than developers. It’s easy for leaders to be willfully ignorant and dismiss these concepts as too detail oriented, and devolves into leaders saying “we’re nice people, trust us”. But the risk is there and someone is accepting it and developers respond to this by mitigating it on their end deep in the implementation details. We have optimized at a local maximum, but are globally suboptimal. I do not believe we’ll ever achieve something more optimal because in business climates, everyone is trying to get something for very little effort. It takes much time to earn trust, but very little time to destroy it. [1] https://en.m.wikipedia.org/wiki/Law_of_conservation_of_complexity https://en.m.wikipedia.org/wiki/Law_of_conservation_of_compl...

astrange 3y ago
> I believe the term for this is resume driven development. This also leads developers to focus on learning new technologies and integrating them to their current project, whereas what the business really needs are stable boring solutions. This can also help recruiting; that's why Uber had all those technical blogs about how super-complicated and full of Scala their solutions were, when Uber's business could be run on a PC under a desk. Also why Palantir is called Palantir. They don't actually do anything cool or spy on people, but the name is intended to help get young tech people to work on boring government work without having to pay them more.

civilized 3y ago

What portfolio? Unless you're open sourcing or squirreling away your company's code via email.