3 ms·

My tips for maintaining velocity and sanity: 1. Ensure your devs are making choices that do not mortgage tomorrow. Anything that gives O(1) value (one new feat

My tips for maintaining velocity and sanity: 1. Ensure your devs are making choices that do not mortgage tomorrow. Anything that gives O(1) value (one new feature) and requires O(n) investment (forever maintaining) is a bad deal. 2. Make as much of your code someone else's problem through FOSS. (This is kinda the same idea as innovation tokens) 3. Solve the generic problem not the specific one. For example, i could write a program that reads a csv row by row, converts it to my internal model, then emits those data into a ndjson file. Or I could just write a program that converts csv to ndjson , agnostic of the data. The former costs you every time the model changes. The latter is useful for a variety of system architectures again in the future. 4. Let the computer do as much as possible for you. Automation is compounding returns. O(1) value from manual testing, vs O(n) value for automated testing, there's a clear winner in my mind. Typed languages prevent a class of bugs, so does TLA+. 5. Most customers wont tell you it's broken, most engineers wont stay to clean up someone elses' mess. Best to avoid those issues or resolve them immediately. 6. Remove broken incentives where individuals leverage everyone else's resources for their own gain. An example of the pattern is "pleased to announce" emails sent to all@. (along with the litany of reply-all posturing). These kinds of emails cost you for every employee, but only bring value to a very small subset of folks. At it's worst you have N^2 cost for 0 value. Ensure individuals can be recognized and promoted without such emails. Disincentivize those who bring that behavior from previous broken cultures.

MajimasEyepatch 4y ago
> Make as much of your code someone else's problem through FOSS. Not all FOSS is created equal. Can you rely on well-established FOSS projects like Linux, PostgreSQL, and Redis? Absolutely! Should you rely on a random library you found that happened to be the first to name itself after a trendy new thing and only has one active maintainer? Probably not, at least not in any important area of your business. If you do, be prepared to fork it or replace it at some point. I know people reading this are going to say, "Duh, of course I wouldn't do that." Congratulations, you understand the concept of risk management. But I have seen firsthand a number of teams fail this basic test. I have spent far too long trying to chase down a bug in some multiselect dropdown jQuery UI library that hasn't been touched in four years. That doesn't sound like it would be that hard to fix, but if it's spread to every important page in your app and is breaking some key features, you're gonna have a bad time. If you're going to make your code someone else's problem, they'd better be just as invested in it as you are.
- maerF0x0 4y ago
  > better be just as invested in it as you are. This is a good chance to plug supporting FOSS through monetary donations (or feature/bug bounties etc programs). If you save $100k from not having to implement something crazy, then consider throwing them $100. Part of what makes FOSS so important to the world is we're amortizing capital costs across many people, and using the "Free" part to break first mover disadvantages and challenges in coordination.
subarctic 4y ago
>Anything that gives O(1) value (one new feature) and requires O(n) investment (forever maintaining) is a bad deal. Maybe a bit pedantic, but wouldn't a new feature give O(n) value over time as well?
h3mb3 4y ago
> 3. Solve the generic problem not the specific one. It's good that you provided the example... > i could write a program that reads a csv row by row, converts it to my internal model, then emits those data into a ndjson file. Or I could just write a program that converts csv to ndjson , agnostic of the data. The former costs you every time the model changes. The latter is useful for a variety of system architectures again in the future. ...because in this case I can agree (although I'd need to drill into the details a bit more). Anyway, far more commonly (in my experience) unnecessary effort is spent on making generic code when a solution only targeting the specific problem in hand would suffice. Then later the requirements change or your original assumptions turned out to be wrong, and you need to spend time changing the generic solution to fit the new problem. This can require 10x the effort vs. just continuing from the specific and simple solution. I guess the difficult art is to be able to recognize those exceptions where it is in fact reasonable to do the extra work for the generic solution. There was a recent submission [1] here about "YAGNI exceptions" which included a few common cases. [1] https://news.ycombinator.com/item?id=33230216 https://news.ycombinator.com/item?id=33230216
- maerF0x0 4y ago
  Yeah I basically try to think something along the lines of "for 10% more effort can I make it so when the Product Manager changes their mind I can either have 0, or minimized additional work to do" . In the case of changing the csv to ndjson, we can actually just treat each row as "just data" and not try to parse it into whatever the PM said.
valand 4y ago
Reminds me of the PAGNI posts from a couple of days ago. 2. This depends on how much you want to have control over your core business technicalities. Open source works wonders if we're dealing with complex standards, but not when the subject needs to change often. 4. Can't argue with that. Go for the extreme route of business object modelling the functional way. 5. Or add analytics when ethical!

MajimasEyepatch 4y ago

> Make as much of your code someone else's problem through FOSS. Not all FOSS is created equal. Can you rely on well-established FOSS projects like Linux, PostgreSQL, and Redis? Absolutely! Should you rely on a random library you found that happened to be the first to name itself after a trendy new thing and only has one active maintainer? Probably not, at least not in any important area of your business. If you do, be prepared to fork it or replace it at some point. I know people reading this are going to say, "Duh, of course I wouldn't do that." Congratulations, you understand the concept of risk management. But I have seen firsthand a number of teams fail this basic test. I have spent far too long trying to chase down a bug in some multiselect dropdown jQuery UI library that hasn't been touched in four years. That doesn't sound like it would be that hard to fix, but if it's spread to every important page in your app and is breaking some key features, you're gonna have a bad time. If you're going to make your code someone else's problem, they'd better be just as invested in it as you are.

maerF0x0 4y ago
> better be just as invested in it as you are. This is a good chance to plug supporting FOSS through monetary donations (or feature/bug bounties etc programs). If you save $100k from not having to implement something crazy, then consider throwing them $100. Part of what makes FOSS so important to the world is we're amortizing capital costs across many people, and using the "Free" part to break first mover disadvantages and challenges in coordination.

subarctic 4y ago

>Anything that gives O(1) value (one new feature) and requires O(n) investment (forever maintaining) is a bad deal. Maybe a bit pedantic, but wouldn't a new feature give O(n) value over time as well?

h3mb3 4y ago

> 3. Solve the generic problem not the specific one. It's good that you provided the example... > i could write a program that reads a csv row by row, converts it to my internal model, then emits those data into a ndjson file. Or I could just write a program that converts csv to ndjson , agnostic of the data. The former costs you every time the model changes. The latter is useful for a variety of system architectures again in the future. ...because in this case I can agree (although I'd need to drill into the details a bit more). Anyway, far more commonly (in my experience) unnecessary effort is spent on making generic code when a solution only targeting the specific problem in hand would suffice. Then later the requirements change or your original assumptions turned out to be wrong, and you need to spend time changing the generic solution to fit the new problem. This can require 10x the effort vs. just continuing from the specific and simple solution. I guess the difficult art is to be able to recognize those exceptions where it is in fact reasonable to do the extra work for the generic solution. There was a recent submission [1] here about "YAGNI exceptions" which included a few common cases. [1] https://news.ycombinator.com/item?id=33230216 https://news.ycombinator.com/item?id=33230216

maerF0x0 4y ago
Yeah I basically try to think something along the lines of "for 10% more effort can I make it so when the Product Manager changes their mind I can either have 0, or minimized additional work to do" . In the case of changing the csv to ndjson, we can actually just treat each row as "just data" and not try to parse it into whatever the PM said.

valand 4y ago

Reminds me of the PAGNI posts from a couple of days ago. 2. This depends on how much you want to have control over your core business technicalities. Open source works wonders if we're dealing with complex standards, but not when the subject needs to change often. 4. Can't argue with that. Go for the extreme route of business object modelling the functional way. 5. Or add analytics when ethical!