Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Move Slow and Make Things

multithreaded.stitchfix.com

Post reply on HN
Print view View original

111–120 of 133 posts

Re: Move Slow and Make Things

#111

Post by bckr »

PartiallyTyped wrote: post #94
ryandrake wrote: post #91

Earlier quoted context omitted.

One of the reasons I left software development as a career was I couldn't bear to keep shitting out products that were just barely good enough that the customer wouldn't return it. That's the quality bar in commercial software and I hated having my name on it. I'm more into refactoring it 20 times in order to get the perfect architecture, fix every last bug, find every performance improvement, make it not just work b…

You will like this presentation by Jonathan Blow [1], I feel the same. I am in grad school, but since my bachelor, I felt more like a craftsman than a student, I always spend more time in order to make my code 'look' beautiful to me, and be performant. I would like to work somewhere that puts emphasis on writing good software instead of chasing feature after feature. Speaking of which, speed is an oft ignored feature…

I think the condition for having this sort of software is that people do it on purpose. The condition for having jobs where people are paid to make such software is that companies focus on areas without competition (otherwise the whole blitzscaling thing applies and they will go out of business). Competition is for losers, right?

What's missing from my extremely simplified model?

Re: Move Slow and Make Things

#112

Post by ampdepolymerase »

TeMPOraL wrote: post #28
bambax wrote: post #24

Earlier quoted context omitted.

> I sent in my measurements and they sent me a trouser with wrong measurements and a postcard that said that they adjusted my measurements with AI for a better fit That is nothing short of hilarious. The machine knows best! Who are you, human, to pretend you are able to measure yourself?! > AI for memorizing generic trends It's possible "AI" may be just a pretext to sell mass-made junk and pretend it is adjusted to e…

> It's possible "AI" may be just a pretext to sell mass-made junk and pretend it is adjusted to each individual. It's also an internal distraction. They'd achieve something much closer to what they promise if they just threw some old-school regression analysis at the problem. But that's not cool these days, plus it's hard to relabel as AI even for the marketroids these days, and would involve actual work :). This app…

Yes, see https://shoesize.me for how it is properly done.

Re: Move Slow and Make Things

#113

Post by NateEag »

ChrisMarshallNY wrote: post #35
dstick wrote: post #16

I know it’s an april fools joke. But I’ve recently “discovered” why this is nevertheless very true. If you move slow, you have a higher chance of meeting the right customer, of actually allowing your idea to grow and improve over time. Without being locked into it in one form or another. Moving slow allows you to work on it as a side project first. Which means no financial stress. And then making things. To me this m…

This pretty much defines how I work. I “move slow,” taking the time to test carefully, and leave clean, concise, well-documented code, but I’m told that I actually move at a blistering pace. I have found there is absolutely no substitute for having an operational, full-feature implementation (I hesitate to call it a “prototype,” because it needs to be fully functional, not just eye candy). I am not a fan of lash-up p…

To prevent a prototype or proof of concept from shipping, you need to leave it feature-incomplete.

The mistake people often make with such things is building it thoroughly enough that it can be shipped.

If you hit that problem, you didn't build a proof of concept - you built sloppy production code.

Re: Move Slow and Make Things

#114

Post by RhodoGSA »

>our staff of mathematicians who will perform all computations by hand using pencil and paper

This part is about when i started dying laughing at every sentence, before i was a bit confused. But only after checking the comments did i realize it was on 1 april.

Re: Move Slow and Make Things

#115

Post by pdimitar »

lanstin wrote: post #95
pdimitar wrote: post #60

Earlier quoted context omitted.

Exactly because it's fundamentally hard, it must be avoided -- we the humans simply can't be trusted with it (speaking as a former C/C++ dev here). It should also be hardware-assisted (if it's impossible to stop it at the hardware level). Stuff like atomic counters were a good first step but the state of the art there hasn't moved in a long time (we don't have atomic 512-bit update operations, do we? if we did, a lot…

Switch to go and channels. You won’t have to worry about locking any more, the design of your program becomes a data flow design issue. (Speaking as a former C programmer). Hardware takes so long to change but more atomicity would be great, but 8n the meantime go runtime is fast, generally lock less to the per request application code flow, and you use all the cores evenly.

Golang's channels and goroutines are only an improvement if you are coming from JS / Python or maybe also suffered complex pthreads bugs in C/C++.

They are an improvement, absolutely, but not a big one.

Re: Move Slow and Make Things

#116

Post by lupire »

konschubert wrote: post #19
dstick wrote: post #16

I know it’s an april fools joke. But I’ve recently “discovered” why this is nevertheless very true. If you move slow, you have a higher chance of meeting the right customer, of actually allowing your idea to grow and improve over time. Without being locked into it in one form or another. Moving slow allows you to work on it as a side project first. Which means no financial stress. And then making things. To me this m…

I think even when moving slow, you can still work with prototypes and get feedback as long as you're open about it and you're not taking people's money. For example, I have https://www.invisible-computers.com up as a website. You can read about the product and you can sign up to be notified. But I won't take a cent until I have a product ready to ship.

Cool product.

1. Why "Invisible"?

2. Why such a thick frame? I hope you expand frame choices, or offer a minimal version that customer can frame.

3. I guess you are building a custom UI layout for the calendar data, but please allow any URL to be loaded in the frame, so the community can build custom data views.

Re: Move Slow and Make Things

#117

Post by pdimitar »

lmarcos wrote: post #41

On a more serious tone: what would take to the IT industry to switch from "move fast and get shit done" to "move slow and make things'? Geninuosly asking. If it becomes a thing, it would only be because the developers push it further... and HN is full of devs. I doubt such a perspective would ever come from "lean" managers and the like.

I feel that at this point nothing except very severe regulatory fines would help.

It's just that the current way of doing things is financially incentivized.

Re: Move Slow and Make Things

#118

Post by lupire »

rectang wrote: post #84

"Move slow and make things" seems like a credo for developer-run Open Source software projects. The software ships when it is ready, not when a commercial entity needs it to. For a tech business, "move slow and make things" can only be a joke. But for a developer collective, it can be real.

Yes. Build the best ideas for posterity.

This is GHC / Haskell philosophy. Golang tries too.

Re: Move Slow and Make Things

#119

Post by lupire »

jmull wrote: post #100

This is the best April fools joke I've seen this year. The article itself is excellent. But the best part is the title is a so much better real credo than the "real" one it parodies.

What happened to all the social netwoks using the Slow credo?

Re: Move Slow and Make Things

#120

Post by ChrisMarshallNY »

NateEag wrote: post #113
ChrisMarshallNY wrote: post #35

Earlier quoted context omitted.

This pretty much defines how I work. I “move slow,” taking the time to test carefully, and leave clean, concise, well-documented code, but I’m told that I actually move at a blistering pace. I have found there is absolutely no substitute for having an operational, full-feature implementation (I hesitate to call it a “prototype,” because it needs to be fully functional, not just eye candy). I am not a fan of lash-up p…

To prevent a prototype or proof of concept from shipping, you need to leave it feature-incomplete. The mistake people often make with such things is building it thoroughly enough that it can be shipped. If you hit that problem, you didn't build a proof of concept - you built sloppy production code.

Good point, but I have found that just doing it right the first time works for me. In fact, I'm doing it right now. In the Xcode window, I'm building a test release that the team will run and review for usability issues and bugs.

If they find any bugs or issues, I fix/address them before moving on to the next function implementation.

The significant advantage that this confers, is that the app is constantly in "release-ready" form; although incomplete.

Useful, for when we want to ask people to give us money. We just get an NDA, loop them into the TestFlight group, and let them have at it. No need for chaperones from Marketing, or sacrifices to the demo gods.

Post reply on HN