How to start and scale a full stack startup • Hacker News Board

Re: How to start and scale a full stack startup

#21

Post by arthurjj » Sun, May 25, 2014, 12:59 PM UTC

icebraining wrote: post #17

mercer wrote: post #4

Earlier quoted context omitted.

I realized exactly this when I wanted to write a backup script for some of my client's websites. My usual process had been to 'manually' backup using rsync, which was a matter of cutting and pasting the commands from a text document. When automating, however, I realized I'd also have to check if certain files (db dumps) were present, and of course if the script itself succeeded. I then realized that in this particula…

Automating is not just about speeding up the process; it's also a way of lowering the bus factor[1] of the process. What happens when you go on vacations, or you get sick? Do the websites stop being backed up? Besides, you should always document your process, and writing a backup script doesn't really take much more time than a detailed description in English. [1] https://en.wikipedia.org/wiki/Bus_factor

Exactly, writing down the steps should be the first step in automating a process. The order I do the steps are:

1. Write down the directions to do the task 2. Have someone else follow your directions. Any time you need to interrupt them because you missed something add a note or additional step 3. See if any part (or the whole thing) is worth automating

Re: How to start and scale a full stack startup

#22

Post by smoyer » Sun, May 25, 2014, 1:15 PM UTC

zaroth wrote: post #11

I think the sad thing here is the idea that code is so expensive and rigid that it's better to slog through something manually, just to avoid the potential of being locked in by code. I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have sta…

"code is so expensive and rigid"

For a former embedded systems engineer, this is a hilarious sentiment ... if code you can deploy to your web server two minutes after you've written it is "rigid", I'd hate to see what the current generation of software engineers would think about not being able to "reROM" an embedded device once it was shipped. Even remote-FLASH capabilities are a pretty recent invention.

I think the main problem the article describes is that if you prematurely write software for a perceived problem, you will often be wrong. Writing software will always be more expensive than some number of manual operations, but those manual operations, in the absence of a clear specification and solution, will help you understand the problem domain in ways you wouldn't have otherwise.

Re: How to start and scale a full stack startup

#23

Post by HenryMc » Sun, May 25, 2014, 2:41 PM UTC

fred_durst wrote: post #10

Anyone know why 42floors blog posts end up on the front page so often?

I was thinking the same thing. I don't come here that often, and this is probably the third one I've seen.

Re: How to start and scale a full stack startup

#24

Post by andyidsinga » Sun, May 25, 2014, 3:48 PM UTC

jliechti1 wrote: post #2

Many engineering types seem to feel more at home making tools to "automate all the things". On the surface, it appears a lot easier than making 100s or 1000s of phone calls, but it can be dangerous because it gives you the feeling of doing important work (not to say it isn't important, but for early stage startups, it's not the highest priority). But I guess everyone is learning that this is not a substitute for all…

wow - I've been using full stack to mean someone who can go from embedded to OS driver to web backend to web front end - add mobile apps too.

i dislike it though, alas ive succumb to the desire to use the hip title in discussion.

Re: How to start and scale a full stack startup

#25

Post by jds375 » Sun, May 25, 2014, 5:30 PM UTC

I think with many founders being software engineers themselves, they naturally steer away from manual solutions (and usually with good reason). But some problems, such as those faces by Uber and 42Floors, simply need manual solutions. That's why it's useful for software-oriented founders to also educated themselves in operations and management.

Re: How to start and scale a full stack startup

#26

Post by fit2rule » Mon, May 26, 2014, 7:37 AM UTC

jliechti1 wrote: post #2

Many engineering types seem to feel more at home making tools to "automate all the things". On the surface, it appears a lot easier than making 100s or 1000s of phone calls, but it can be dangerous because it gives you the feeling of doing important work (not to say it isn't important, but for early stage startups, it's not the highest priority). But I guess everyone is learning that this is not a substitute for all…

For me "Full Stack" means: there is no stack.

Its difficult to argue about this with academic reasoning, but my 'feelings' after 30+ years in the software business is that the more you treat the artificial borders between technologies as insignificant, the less significant the effort required to grasp the technology. In other words, there are no real 'borders'; these are self-imposed on the individual programmer, socially, in sometimes very sexy packages. "Framework Developer" is another nasty phrase arising, in my opinion, because what does it mean? You use the framework, or you build one?

Either way, this artificial division allows for the ordering of 'developer skills' in such a way that one higher skilled programmer can sell the other lesser but nevertheless competent, programmer .. something.

There is no Stack, means, if you need to know something about your computer, you can. Dig into its depths faster and with more passion, not slower, because 'there is no way to understand it all' is a fallacy. You can, indeed, understand every single thing that the computer is doing; it was made that way.

Re: How to start and scale a full stack startup

#27

Post by zaroth » Mon, May 26, 2014, 8:40 AM UTC

smoyer wrote: post #22

zaroth wrote: post #11

I think the sad thing here is the idea that code is so expensive and rigid that it's better to slog through something manually, just to avoid the potential of being locked in by code. I get that sometimes automation sets you on a course of infinite refinement, and you end up investing more money that you should have making some tool cover 100% of all possible use cases. But that doesn't mean you never should have sta…

"code is so expensive and rigid" For a former embedded systems engineer, this is a hilarious sentiment ... if code you can deploy to your web server two minutes after you've written it is "rigid", I'd hate to see what the current generation of software engineers would think about not being able to "reROM" an embedded device once it was shipped. Even remote-FLASH capabilities are a pretty recent invention. I think the…

I said 'the sad thing is the idea that code is so expensive and rigid'. I personally don't think that code is particularly expensive or rigid at all, perhaps least of all this type of specialized task automation code.

I guess there are two ways that you "will often be wrong" when automating a specific task. 1) You could improperly or so incoherently automate the task that it actually is harder to for your users to accomplish the task with the tool -- failure to improve productivity of the stated task, or 2) you could successfully automate the task at hand, but either the improvement is too minimal, the task is too rare, or the code cannot be well leveraged when the task needs to change, meaning you never get to break-even on the investment. Both failure modes can be well defended against by a good PM.

Are you saying, that by shipping some automation code, now just by nature of having the tool in the workforce's hands, they are actually less able to understand the problem domain and come up with better ways of doing things in the future?

I think of it a bit differently; the automation of a given approach gets so good that a competing idea that could actually produce a better outcome, but must be done completely manually, is so inefficient compared to the automated workflow as to result in a negative effect, and so it's dismissed. (E.g. you earned an extra $10k on this client doing it your way, but if you used the automated fast-path, you could have just closed 5 more clients at $10k each in the same time).

One way I see this often manifest is the idea that sales always wants to be able to say YES to the prospect / client. If you have a large software automation toolset, you only say YES when the needs match the capabilities, because you lose money every time you work on the special-case clients. I think basically you sacrifice growth rate in this case in order to be a jack-of-all-trades.

Re: How to start and scale a full stack startup

#28

Post by smoyer » Mon, May 26, 2014, 12:42 PM UTC

zaroth wrote: post #27

smoyer wrote: post #22

Earlier quoted context omitted.

"code is so expensive and rigid" For a former embedded systems engineer, this is a hilarious sentiment ... if code you can deploy to your web server two minutes after you've written it is "rigid", I'd hate to see what the current generation of software engineers would think about not being able to "reROM" an embedded device once it was shipped. Even remote-FLASH capabilities are a pretty recent invention. I think the…

I said 'the sad thing is the idea that code is so expensive and rigid'. I personally don't think that code is particularly expensive or rigid at all, perhaps least of all this type of specialized task automation code. I guess there are two ways that you "will often be wrong" when automating a specific task. 1) You could improperly or so incoherently automate the task that it actually is harder to for your users to ac…

I totally missed "the idea" - it seems like we're in violent agreement!