3 ms·

OP here. I was working on a feature for a webapp that I thought should be doable in a day, but I spent roughly a week on it. When I was done with it, I looked

by hsn915 3y ago

OP here. I was working on a feature for a webapp that I thought should be doable in a day, but I spent roughly a week on it. When I was done with it, I looked back and thought: wait, why did this take me the whole week? I couldn't come up with a satisfying answer. So I just decided to accept that I'm not that productive. Maybe there are things I can do to improve my speed of implementing features, but for the time being, this is my speed. I was going to make a writeup about coming to terms with that. But somehow as I was writing (originally on Twitter) I linked it in my head to the way I hate modern dev culture: the docker and the webpack, etc. Programming is already hard, why make it 10x harder with all the tools that require complex configurations, etc? I remember raising this point on HN and other places with other developers, and that there was always push back from people who swear by these tools. So it clicked in my head: I hate these tools because I'm already slow as it is and I can't take it when these complexities slow me down even further. Then as I spent more time thinking about the content, I thought this a manifesto worthy content. But in terms of the points mentioned: I'm dead serious about all of them. Although what I actually mean might not be obvious from first glance. When I said I write objects as-is, it appears that most people in this thread thought I'm writing individual files. This is not what I'm doing. I'm using a B-Tree backed key-value store and doing binary serialization. I also have a scheme where I make use of the properties of B-Trees to make indexing/querying possible. I have a whole write up about this topic: https://hasen.substack.com/p/indexing-querying-boltdb https://hasen.substack.com/p/indexing-querying-boltdb For using HTTP as a medium for RPC, I also have a writeup: https://hasen.substack.com/p/automagic-go-typescript-interface https://hasen.substack.com/p/automagic-go-typescript-interfa... These alternative techniques took time for me to develop, so you could say that it would have been faster for me to just use postgres/docker/aws etc (the standard stack). But this is my point: I really am too stupid to learn them.

pm 3y ago
There are plenty of reasons why something you think should take a day might take a week. We often (fallaciously) assess a problem as "easy" without considering the context in which it has to be incorporated, i.e. the codebase. The duration is moreoften a function of the complexity of the codebase, rather than the complexity of the isolated problem.
softfalcon 3y ago
We've all been there. Things take much longer than expected. This is, as you've already stated, something we come to realize in our careers. However, I would like to share a different angle, if I may. I don't think your speed is necessarily the problem. I think your time estimation skills might need some work. It's easy for us to think things "should be simple". Unfortunately, the modern world of software is becoming more and more diverse and complex (a symptom of software "eating the world"). It's only natural in a world that has evolved from 8086's and terminals to interconnected-everything, multi-OS, multi-platform, multi-device magic is going to be orders of magnitude more difficult to build on at any reasonable scale of business. There are just so many small things that can go wrong! I would gently suggest you stop being so hard on yourself and instead of beating yourself up for "being slow" just take each technology one at a time. Ultimately, the way to survive in this career is embracing change and staying sane while doing it. It's not easy, but it's the only way. As for you being dumb, I would also like to say that it is clear you choose to deeply understand the topics you put in your head. Many folks "learn enough to get the job done" and very little more. It seems you have an appreciation for deep learning. This is not a bad thing, it is usually this trait over a long time that differentiates a truly senior engineer from an intermediate one. Your path may be slower, but it is probably more thorough and more informative in the long term. Keep in mind though, this breeds imposter syndrome in your mind. When you accept you still have lots to learn, it is easy to feel like you know nothing at all. I would suggest not letting this get to you. We all feel it, it is real, we're all just trying to do our best day-to-day. Oh, and always 2x pad all your estimates at minimum, cause if we know anything about computing, it's that it always has hiccups.
- hsn915 3y ago
  It's ok man. I don't need to be cheered up. It's completely fine to accept your situation without giving up on improving it. The problem is when people refuse to acknowledge reality because they really hate certain labels and are too invested in not having that label apply to them. I'm slow and it's ok. I'd like to become faster in the future. But for now, I'm slow, and that's ok.
  - softfalcon 3y ago
mcv 3y ago
Wait, so you made your own database? That's the thing I'm not smart enough for. I'd rather just use an existing database.
- hsn915 3y ago
  I mean, not really. The hard work was done by benbjohnson who is now working on https://litestream.io/ https://litestream.io/ and https://fly.io/ https://fly.io/ He's the one who wrote BoltDB https://github.com/boltdb/bolt https://github.com/boltdb/bolt I just put a relatively thin layer on top of it. Now, to address your point more directly: I'm too stupid to figure out configuration, but not too stupid to figure out code. Code gets compiled and type checked. You can have tests, etc. Tractability for code is much higher than configuration. With configuration, you have to be really smart and keep many moving parts in your head. With code, you can be a bit dumb and lean heavily on the tooling.

by hsn915 3y ago

pm 3y ago

There are plenty of reasons why something you think should take a day might take a week. We often (fallaciously) assess a problem as "easy" without considering the context in which it has to be incorporated, i.e. the codebase. The duration is moreoften a function of the complexity of the codebase, rather than the complexity of the isolated problem.

softfalcon 3y ago

We've all been there. Things take much longer than expected. This is, as you've already stated, something we come to realize in our careers. However, I would like to share a different angle, if I may. I don't think your speed is necessarily the problem. I think your time estimation skills might need some work. It's easy for us to think things "should be simple". Unfortunately, the modern world of software is becoming more and more diverse and complex (a symptom of software "eating the world"). It's only natural in a world that has evolved from 8086's and terminals to interconnected-everything, multi-OS, multi-platform, multi-device magic is going to be orders of magnitude more difficult to build on at any reasonable scale of business. There are just so many small things that can go wrong! I would gently suggest you stop being so hard on yourself and instead of beating yourself up for "being slow" just take each technology one at a time. Ultimately, the way to survive in this career is embracing change and staying sane while doing it. It's not easy, but it's the only way. As for you being dumb, I would also like to say that it is clear you choose to deeply understand the topics you put in your head. Many folks "learn enough to get the job done" and very little more. It seems you have an appreciation for deep learning. This is not a bad thing, it is usually this trait over a long time that differentiates a truly senior engineer from an intermediate one. Your path may be slower, but it is probably more thorough and more informative in the long term. Keep in mind though, this breeds imposter syndrome in your mind. When you accept you still have lots to learn, it is easy to feel like you know nothing at all. I would suggest not letting this get to you. We all feel it, it is real, we're all just trying to do our best day-to-day. Oh, and always 2x pad all your estimates at minimum, cause if we know anything about computing, it's that it always has hiccups.

hsn915 3y ago
It's ok man. I don't need to be cheered up. It's completely fine to accept your situation without giving up on improving it. The problem is when people refuse to acknowledge reality because they really hate certain labels and are too invested in not having that label apply to them. I'm slow and it's ok. I'd like to become faster in the future. But for now, I'm slow, and that's ok.
- softfalcon 3y ago

mcv 3y ago

Wait, so you made your own database? That's the thing I'm not smart enough for. I'd rather just use an existing database.

hsn915 3y ago
I mean, not really. The hard work was done by benbjohnson who is now working on https://litestream.io/ https://litestream.io/ and https://fly.io/ https://fly.io/ He's the one who wrote BoltDB https://github.com/boltdb/bolt https://github.com/boltdb/bolt I just put a relatively thin layer on top of it. Now, to address your point more directly: I'm too stupid to figure out configuration, but not too stupid to figure out code. Code gets compiled and type checked. You can have tests, etc. Tractability for code is much higher than configuration. With configuration, you have to be really smart and keep many moving parts in your head. With code, you can be a bit dumb and lean heavily on the tooling.