3 ms·
A good generalist will not change your tech stack on the fly. Of course that’s a bad idea. I think what GP meant is more like they will be willing to change wh
by ghiculescu 4y ago
A good generalist will not change your tech stack on the fly. Of course that’s a bad idea.
I think what GP meant is more like they will be willing to change what they are working on day to day in response to what you learn from the market, and will be fine with throwing lots of things away if they don’t work.
If you focus on foundational work too much that comes with the trade off that you can’t spend as much time building features. It’s common to see engineers fall into this trap.
- ivan_gammel 4y agoIf we are not talking about one person team, frequent context switching is counterproductive and same jobs are better done by two specialists (e.g. FE and BE) than two generalists. It’s also a common trap to build a lot of features without any evidence that users need them, 30-40% of effort wasted on something that does not have enough business value or on validating with code hypotheses that could be validated by one email with typeform.
- matai_kolila 4y agoNooo, as literally a person doing this right now, splitting up the work is a terrible idea. Almost everything you do is "wasted" effort at this stage (until it suddenly isn't, and arguable if failed experimentation is "wasted" in the first place), you need to be okay with that when in this role, and everyone needs to know how to do everything if you want to even have a prayer of a chance at a normal life. You must learn new tech quickly, and pivot to different decisions if it makes more sense to do something another way. You also must be okay with terrible code written hastily, as long as it's good enough to not have any fatal bugs in it, and the only way I know how to do that is to have another person to validate/refute your work.