Code Is Never "Perfect", Code Is Only Ever "Good Enough" - <AUTHOR> https://www.exceptionnotfound.net/code-is-never-perfect-code-is-only-ever-good-enough/ <comment><USER3> One of the depressing things about code is that it is astoundingly easy to build something that does amazing things in controlled circumstances but is otherwise practically garbage. Promotions, venture capital, and all other manner of rewards can result from said garbage. The "real work" is in figuring out how to move forward from something like that, and lots of stress comes from trying to do so without breaking anything. There is little reward in maintenance.

"Good enough" is really the type of attitude that leads to this unfair balance of effort.

Unfortunately, we live in a world where criticism is levied very heavily on where you are now, and not on how you got there. What, version 2.0 of the product sucks now? Screw it, "1 star", boycott this; fire the team responsible! Never mind the fact that version 1.0 was a rickety mess, all of those guys left, and _anyone_ would be _lucky_ to get the thing working _at all_ , much less in a way that does not introduce any new bugs.

One of the big benefits of open-source is having a chance to understand what's going on. Would as many people invest in a product, despite promising behavior in version 1.0, if they could see a critical review of how that version was actually implemented? Ideally, we can see not only how a product appears to work, but how well-engineered it is according to experts.

<comment><USER4> What you say is indeed important, but I wouldn't say the work before that is not "real work". It's just different types of work. Ask any successful startup founder what their initial codebase was like and they would say--if they're honest--it was shitty.

There's a reason for this. The "real work" you mention comes into play only after the product has reached product market fit and needs scaling. Before that phase, it's all about struggling to make things work, and people don't have time to refactor everytime they need to make a small tweak and experiment. So naturally by the time the "real work" guys come in they will think "WTF the code is so shitty, whoever wrote this is an idiot". But they should know that they're there only because of that shitty code. If they were in that same situation (and rational) they would have done the same thing-- write a consequentially shitty code.

<comment><USER5> Early work is closer to a lottery than anything else. If you only look at winners you will end up with a distorted view, but right product, right time, right market is more about luck than skill. MVP is all about validation because there is no way to judge good vs great before you build it. So, the only way to improve odds is to just roll more dice.

<comment><USER6> You can still write great code (meaning: clean non-leaky abstractions, proper separation of concerns, functional testing, clearly organized, and unintuitive bits documented) without having market validation, and I'd suggest that doing so will actually make it a lot easier for you to shift the pieces of the project, remove them, rewrite them, extend them, etc. as you start to hone in on the marketplace fit, and doubly so as you need to start growing your development team and need to on-board them effectively so everyone can be productive without just rapidly accruing compound interest on the technical debt that's already there.

It doesn't take _that_ much longer to write great code when it's just part of the first-principles of your engineering process. You just do it as you go, but best-practices need to be scaffolded and modelled for everyone beforehand to give them a solid starting point for what "minimally viable" actually looks like. A single well-placed sentence that describes something necessary, but non-idiomatic or non-obvious, that takes 10sec to write can save you hours or days of tracing and debugging at that crucial moment right before you're onboarding a pilot customer or pitching investors.

Very often the bar of "minimally" is set way, way too low and the trope of that just being "startup life" is usually just laying problems at the feet of engineering that don't belong there by justifying, sometimes horrifying, technical debt which are really process and management failures, and later eventually scapegoating engineering for it.

<comment><USER4> I agree with you in theory, but from experience it is extremely hard to achieve when you're actually in that position.

Unlike what you say, it _does_ take much longer to write great code when you're trying new things every day. Every time you try something new, by definition you're building something that you hadn't planned when you first started. Which means if you really wanted to be perfect you would end up refactoring every day. This is not a small effort in total.

You could say you should have prepared for that scenario from the beginning, but I don't think it's a good idea to believe that you can predict the future especially when you're building something that hasn't existed before.

<comment><USER6> In my experience, when you're in the "invention phase" is when it's most critical and beneficial to have and demand more discipline around your output artifacts. Precisely because keeping context and content around your fast iterative decision-making and implementation phases is critical to avoid wasting time on duplicated effort or needlessly repeating mistakes over and over again.

Literally every situation I've ever seen in 20 years across all manner of marketplaces and every imaginable stage of development has had the immediate faux-gains made from ignoring spending 10%-20% more time now (to produce something at least coherent, commented, and composable) ultimately overwhelmed by the soon-to-be-immediate costs of having to live with the consequences of the dubious "shortcuts" taken.

I agree with you that it's extremely hard to achieve maintaining that kind of discipline when under the gun, but that's a people management and expectations problem, not an engineering effort problem. I'm 100% certain that in any given window of time, no matter how crunchy that crunchtime is, that if my team spends 10-15 out of every 100 man-hours producing a higher-quality "minimally acceptable" artifact that they'll both materially accomplish more in that first 100 hours than if they'd spent all of it hacking together a barely working dumpster-fire in the same window of time, _and_ that it will pay glaringly obvious dividends for their productivity in the next 100 hours after, and the next after that, and so on.

Lacking that discipline is neither a necessary condition nor a near or long- term benefit to a prototyping or product development cycle. It's purely a function of leadership, expectations management, and experience.

 _(I 'm even giving the benefit of the doubt that what's being done "hasn't existed before", which is overwhelmingly not the case. More typically it's different people and different teams just painfully learning the same hard lessons in parallel, often because there's an assumption/delusion what's being done is a legitimate pioneering effort instead of the probable reality that it's really a minor variation on something else that already has well- established successful models available to learn from and mimic.)_

<comment><USER7> > I'm 100% certain that in any given window of time, no matter how crunchy > that crunchtime is, that if my team spends 10-15 out of every 100 man-hours > producing a higher-quality "minimally acceptable" artifact that they'll both > materially accomplish more in that first 100 hours than if they'd spent all > of it hacking together a barely working dumpster-fire in the same window of > time, and that it will pay glaringly obvious dividends for their > productivity in the next 100 hours after, and the next after that, and so on

The problems is at the very beginning, all (or most) of that code will be thrown away because you really don't know what works. How many cycles of wasted extra 20% effort would it take for you to change your mind?

<comment><USER6> You missed the point. In that same 100 hours, spending 15-20 hours applying best-practices has universally resulted in actually getting _more_ out of that 100 block. The 100 hours spent on the spaghetti mess has always produced less, provided fewer insights, and often exactly nothing that can be soundly iterated on.

This is because the friction and pain of technical debt doesn't wait until the end of the 100 hours to create problems. It's biting you every second of every minute of every hour and dragging down your productivity and velocity as you're just plowing forward soaking the noodles.

<comment><USER4> It really depends on what one's standard of "shitty code" is, but in my case my shitty code does perfectly fine until it reaches significant scale (as in millions of users). My thought process is: when I reach millions of users i better hire someone to help me with coding anyway and it's not too late to take care of it then.

On the other hand, I have also made mistakes of over-engineering to make the code maintainable. What happens then is I can't really detach myself from the original idea no matter how much evidence there is to show me that it's not working, since I've invested so much in the technology. In that case the time I spent to make the code maintainable becomes a mental liability rather than an asset.

I don't doubt you are a great developer and have great experience, and I don't doubt that spending 15-20 hours out of 100 hours when you've reached product market fit is something you should do, but I can say from my own experience and experiences from other successful/failed entrepreneurs I've met that it's absolutely a bad idea to do so when you're just 1-3 guys bootstrapping. In the beginning the only thing that matters is getting people to actually use your product, so you should spend 100% of your resources on getting there, not on optimizing maintainability at all.

If you have actually been in that situation (a founder who's built his own product from scratch by bootstrapping) and still think it's best to spend 15-20 hours out of 100 hours working on maintainability, please let me know. I personally don't know any founder who thinks that way.

<comment><USER6> I'm also not sure why we're narrowing down that 15-20 hours focused entirely on maintainability.

It can also be 15-20 hours making sure you're following language/tool idioms and conventions so that you can iterate quickly instead of fighting against yourself and your tools being used incorrectly.

It can be about making sure you aren't making leaky abstractions so that when you suddenly realize you need to make big or small changes to address market needs you're able to do it quickly and efficiently rather than having to rewrite a big brittle pile of al dente noodles with every shift and change you're presented with.

It can be about making sure that the little idiosyncratic things you had to do have some explanation around them so when your fellow boot-strapper has to come in and make a change or understand something you worked on, but you're home sick as a dog because your kid sneezed straight down your throat, your fellow boot-strapper can understand what you did, why you did it, and can carry forward with that change without depending on your availability holding everything up, and because you didn't make a bunch of leaky abstractions on top of it all they can make that change without breaking 99% of the rest of the prototype/product.

It can be about making sure a sufficient amount of what you're doing is done so with composability in mind, so that when you figure out that thing you did that you ended up throwing away, but now turns out would be supremely useful to meet current demands, both still exists someplace and can actually be used without having to spend 10x as long rewriting it.

Having great scaffolding, best-practices models, and good process makes everything go faster... not slower. Learning how to properly use your VCS is an enabler, not a drain, but it takes time away from just hacking away on something. Setting up a CI pipeline is an enabler, not a drain, but it takes time away from just hacking away on something. Building scaffolding tools that can just generate for you the first 20% of a project template are an enabler, not a drain, but it takes time away from just hacking away on something. Learning your tracing and debugging tools is a _massive_ enabler when trying to understand and prototype something, but it takes time away from just hacking away on something.

I should add the caveat that all those things are enablers... only if you do them well... otherwise they're a giant drag because they're hurting you, not helping you, and they become a part of your technical debt.

Do you spend literally no time on any of that because it takes time away from hacking? Do you think having none of those enablers in-place is helping you all work faster?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and perfect!). That usually involves finding the mathematical meaning of the abstractions you're using. (Shameless plug- I wrote a little blog post on the subject: [http://asivitz.com/posts/programming_in_haskell](http://asivitz.com/posts/programming_in_haskell))

<comment><USER9> Actually, I'd say writing perfect code in the mathematical domain is extremely hard - floating point types are a minefield and infinite-precision arithmetic is a minefield also if you consider the possibilities for running-times exploding. For example, code for the mean of a list of numbers is a hard problem when looked at in its full generality [1] - and that's using forgiving definition of "perfect" \- alway correct and terminating, running at a reasonable speed.

[1] [http://hypothesis.works/articles/calculating-the- mean/](http://hypothesis.works/articles/calculating-the-mean/)

<comment><USER10> Great link! But also, the mean is itself an imperfect summary of some distributions. Any single-number summary will be misleading in some cases.

<comment><USER11> Anscombe's quartet is a great illustration of that.

[https://en.wikipedia.org/wiki/Anscombe%27s_quartet](https://en.wikipedia.org/wiki/Anscombe%27s_quartet)

<comment><USER12> That's really cool! Btw, I'd love to drop that line into casual conversation some time. "Anscombe's quartet" has a nice flow to it.

</comment></comment></comment></comment></comment><comment><USER13> I had a manager that never used "finished" or "done". He always said "where it needs to be right now".

</comment><comment><USER14> I have the start of a lightning talk on something similar, called "Why Software Sucks". The idea is that we only make software good enough to get by - we will always choose features over robustness if we possibly can. Every project ends when it either fails, or hits feature-complete. No one sits around polishing the pile of bugs and bad decisions that is a feature-complete app unless they have to - much more fun to start something new!

<comment><USER15> It seems like most consumer apps incur a crazy amount of technical debt while largely paying people in equity, then if they take off raise a bunch of money to pay other people in cash to sort it all out... Pretty good system actually.

<comment><USER14> Enterprise apps are no different. Lean startup is doing better in the enterprise than it is in the "startup" world.

Early on, every app is laden with technical debt. They barely work. When "barely works" becomes "doesn't work", we fix them just enough so they barely work again, and start piling on more features and functionality. We may build some scaffolding and do some refactoring to prevent dropping into doesn't-work-land, but that's not the same as robust! So software - <USER2> software - hovers around that barely-works/doesn't-work borderline.

<comment><USER16> Management doesn't invest in things they don't understand. They rarely understand tech (even if they are technical people, tech is misunderstood).

If you care about the outcome of a craft, you'll get craftsmen, and they'll produce things and you'll pick the best ones.

Imagine if a chef had to serve the first try at a new dish, if a photographer had to use his first shot, if a director had to use the first take, if a visual designer had to use the first concept. These processes are easier for people to understand because a layman can tell if two flavors didn't combine well, if a model blinked, or if something looks off. People (even technical ones) can't experience technical problems immediately or directly in the same way. Other fields solve for this with engineering, but ours rarely is allowed.

We often ship the first architecture that gets brainstormed, and the first implementation that works. It's never "We implemented the MVP using patterns/frameworks A, B, C, D, here's a table of the strengths and weaknesses as we see them, statistical summary of the time to complete each feature, and of defect rates. This next slide is a plot of the relationship between request latency, capacity, and estimated infrastructure cost of each implementation". It's rare to even have refactors scheduled. Just cleaning up your shit is "wasting time", never mind how long it takes to ship new features given how cluttered things are.

Sure, engineering is costly, so is not engineering - you just aren't projecting or measuring the latter costs. It's all trade-offs, if you aren't considering expected values of different options, with numbers, then you haven't optimized, you just rolled some dice. Sure, of course it's always worked, everything always have worked for the survivors. There's a big difference between what's unforeseeable and what has merely been left unforeseen.

<comment><USER14> If my house is on fire, I don't want the fire department to wait for the better firetruck for the job to show up.

Time to market and allocation of resources are serious issues for management. They may not understand the tech, but I've found engineers rarely understand the business context, either. "Good enough" is _good enough_. And we've seen process get more and more focused on this since the late '90s... Agile, Lean, etc. Get a product out the door, even if it's buggy and flawed. Get feedback from actual customers. Find out what's really a problem and what we only think will be a problem.

<comment><USER16> Right, there's a whole spectrum between "a prototype worked once on Bob's laptop, how do we get that live" and "We invented 12 new declarative DSLs that encompass our problem domain, and formally proved their implementations correct."

Engineering isn't the latter end of that, it's precisely just the process of figuring out the trade-offs, the diligence of figuring out where on that spectrum (highly-dimensional continuum really) of process your project should be to get the greatest chances of success. Of course it includes time to market and concepts of "good enough". But it's math and planning and risk accounting and not the cargo culting, handwaving, business platitudes, salesmanship and politics of authority that get utilized in the majority of cases I've seen for making those decisions. These result in monuments to compromise -- the output of arguments between "captain cowboy" and "doctor diligent" (neither of which correctly account for real-world incidence of risk or what that costs the organization which employs them), arguments of engineering without any engineering being done.

Engineering isn't disconnected navel-gazing perfectionism, it's how you prevent it. Engineering is both why we don't live in Kowloon Walled cities, and why most places have water and plumbing and transportation despite a wide variety of obstacles and economic realities that would preclude "ideal" solutions.

</comment></comment></comment></comment></comment></comment><comment><USER17> It might not be _" perfect code"_, but I find it fascinating what certain institutions do to create _bug-free and easily testable code_ , institutions which are involved in work where small errors can quite literally ruin billions of dollars of investment.

For example Coding Standards from NASA's Jet Propulsion Laboratory (JPL) for C[1] and Java[2]

This will also give you an idea of just how tedious it is to do so

I am not even sure if enforcing those strict standards leaves a Turing- complete language

[1] [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf](http://lars- lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf)

[2] [http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_Java.pdf](http://lars- lab.jpl.nasa.gov/JPL_Coding_Standard_Java.pdf)

<comment><USER18> That's a good point. Safety critical systems commonly require loops to have maximum iteration counters and also forbid recursion.

So what's left probably isn't Turing complete.

<comment><USER19> From [2] above:

> important general differences from the JPL institutional C coding standard > for flight software references (JPL-C-STD) are: (1) the Java standard allows > dynamic memory allocation (object creation) after initialization, (2) the > Java standard allows recursion, and (3) does not require loop bounds to be > statically verifiable. Apart from these differences most other differences > are due to the different nature of the two languages.

That said, the standard in question is explicitly only intended for ground- based systems.

</comment></comment></comment><comment><USER20> Perfect is subjective, but "correct" not so much. And when you get sufficiently skilled, you realize correctness can, for sufficiently complex software, only come together with the more subjective qualities, since it's hard to make "ugly" code correct.

"Piece of [bleep]! I know you [bleeping] work! WHY WON'T YOU [BLEEPING] WORK, MOTHER[BLEEPER]?!"

With that kind of attitude (trial-and-error?) you will never be able to consistently produce correct code, let alone perfect whatever that is. Though I think it's not typically the attitude that is the problem, but rather the underlying lack of skill/intelligence which makes people resort to such approaches.

<comment><USER21> > With that kind of attitude (trial-and-error?) you will never be able to > consistently produce correct code, let alone perfect whatever that is.

Sometimes software development process can be very frustrating and I fully understand the feeling when you're overwhelmed and confused and feel frustrated because you don't know how to approach the problem. Working with black boxes usually causes the feeling in me, or having an elusive bug that could come from literally anywhere from a huge system and having to debug it with seemingly random reproduction steps, that always gets me.

</comment></comment><comment><USER22> Code quality can only ever be as good as your understanding of the problem domain. A more accurate statement would be "Problem domains are rarely perfectly understood."

<comment><USER23> IMHO This should be more highly rated. It seems that we write code to understand the problem domain, and only by writing code do we truly understand the problem. This is - again IMHO - why iterative techniques work so much better than waterfall-style techniques.

</comment></comment><comment><USER24> It's scary sometimes that previous consultants (I'm a consulting developer) may have gotten an application "working", but have incurred so much technical debt it is nearly impossible to make changes. They've escaped and taken the biggest chunk of money leaving something built on a foundation of toothpicks. Thus the project becomes a ticking time bomb and requires full-time programmer maintenance. You wonder if the next feature request will become the impetus for the collapse- Then you turn into Robert Gates: "I don't know where. I don't know when. But something bad is going to happen!!!"

</comment><comment><USER25> I'll copy a Bruce Schneier's quote and say "Software is a process, not a product."

It's no surprise that there's no such thing as perfect code because code is mere reflection of a real-life requirement, which is always somewhat inconsistent and ever changing. Sticking to one static point is, well, pointless.

</comment><comment><USER26> I think today it's more useful to think of most software as a living organism interacting with it's environment - it's constantly evolving and adapting to external changes (user needs, dependencies, 3rd party services etc.).

</comment><comment><USER27> I still haven't learned this lesson well enough. Code I think is near perfect always turns imperfect over time. The main corollary for me is that I can spend every waking second of my life making my code better, and I'll never be happy. I want to better figure out how to enjoy 'good enough'.

<comment><USER28> Instead, I might suggest that you enjoy making your code better and to be happy with the process rather than the result. Then every crappy piece of code is an opportunity rather than a curse.

Improving code beyond the point where it gives material benefit is not really a problem except for the fact that it deprives you of the opportunity to work on crappier code. Especially when working with new code, I find it useful to concentrate on process rather than end product. If you write tests like X and refactor like Y, how does it affect the result?

In some ways this is really freeing because you get over the fear of writing crappy code. If it's crappy, you just get to improve it. It also allows you to explore ideas and ways of doing things without worrying so much about the result. Concentrating on producing good code can often (in my experience) lead to achieving a local maxima but not does not allow you to kick out of it to achieve something better.

<comment><USER27> I was getting closer to that for many years -- enjoying the process -- until I decided to try and start a software business. All of a sudden, there's a huge downside to improving code without having a clear material benefit.

I'm with you on losing the fear of writing crappy code being freeing. At some point I realized that everyone's code including mine is crappy code, and there's no way around writing crappy code or introducing bugs. Realizing that did make me a better coder and a better manager. It let me be a bit more humble as well as empathetic to others, and led me to think more about the importance of testing.

</comment></comment></comment><comment><USER29> I wonder if this attitude will change once things like coq become more accessible.

<comment><USER30> I don't know if we will ever have tools that are that safe and _as easy to use_ as the alternatives.

<comment><USER31> It depends. People were reluctant to give up a lot of bad coding practices (goto, variable scoping, writing in efficient assembly rather than a high- level language, mutable global state) until the better way had better tools or was taught better.

Edit: Maybe one day people will look back and say, "you shipped code _without_ formal correctness proofs? Were you all high?"

<comment><USER32> There is code that pushes the boundaries of the human mind, complex systems that cannot have any additional complexity if they are to succeed.

And there's other code that pushes against physical or economic limits: processor speed, memory available, network latency. In those systems, writing in an inefficient, high level language is just as wrong as writing the first type of code in a low level one.

Fast, complex, difficult to fully verify code is not bad coding practice any more than a rocket is a worse vehicle than a Volvo because it explodes more. Volvos can't go to space.

<comment><USER31> But one day our skill in "controlling explosions" (bad logic) may be as good as our skill at doing so in a Volvo, where we can get the power, with the efficiency and predictability.

</comment></comment></comment></comment></comment><comment><USER33> The obligatory link to "Everything is Broken": [https://medium.com/message/everything-is- broken-81e5f33a24e1](https://medium.com/message/everything-is- broken-81e5f33a24e1)

</comment><comment><USER34> This reminds me or a reaction I had to a very old internet war about PHP and Rails

[https://sivers.org/rails2php](https://sivers.org/rails2php)

"...The entire music distribution world had changed, and we were still working on the same goddamn rewrite. I said fuckit, and we abandoned the Rails rewrite."

It made a bunch of people mad, because (I think) they were reading "Rails couldn't X, and Rails couldn't Y, and Rails couldn't Z, but PHP could totally Y Z and Y, so I used PHP and it was a big success".

But having been in this situation, I think what he was saying was "I couldn't X, and I couldn't Y, and I couldn't Z, so I said fuckit and did it the way I know how..."

It has nothing to do with rails or PHP, or node, django, react. Programmers who have never finally said "fuckit" and abandoned "the true and right way" are programmers who haven't released.

Not saying you should stick with ancient technology, but "good enough" is an inevitable ingredient in any software that ends up being useful to someone.

</comment><comment><USER35> I think this is rambling about things that are largely unimportant (spaces or tabs). At least that's what his "Perfect Code" definition seems to be to me.

The important part is the flipside, not the presentation: Given a problem domain and a context there is an optimal or "best" solution or there is not, and we can get at the answer for most cases.

So code can be perfect if we understand perfect to mean optimal. If we understand it to mean spaces/tabs probably not, though given an input and desired output we can even prove some of these as well (for instance, underscored function names are more quickly processed than CamelCase : [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158....](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499)).

<comment><USER36> I didn't read the whole paper you linked, but doesn't this sentence in the abstract contradict your last sentence?

>Results indicate that camel casing leads to higher accuracy among all subjects regardless of training, and those trained in camel casing are able to recognize identifiers in the camel case style faster than identifiers in the underscore style.

<comment><USER35> yes it appears that way without reading the paper. Basically the main factor to me is speed which has a huge differential for untrained subjects "The model finds that identifiers written in the camel case style took 0.42 seconds more time." Doing the math you see how much wasted time that is. So I should have been more specific in the parameters. Your quote is perfectly valid as well.

</comment></comment></comment><comment><USER37> It's important to know what kind of code you're working on before you start setting low standards.

Some code is perfect, but it's only perfect because it was define with extreme mathematical precision (Ex: Haskell Prelude code). The value of this type of code is in direct proportioned to how often it's reused. Often the specs are based on timeless and well defined ideas, and the implementation crystallizes.

On the other end of the spectrum is loosely defined ad hoc code. The specification behaves more like a living thing and the code often tries to adapt to the moving specification over time. This type of code tends to bring a lot of value to the business and often relies on the foundations laid by perfectionist code.

<comment><USER38> I wouldn't call Haskell's prelude 'perfect'. For a few examples of imperfect things see [https://downloads.haskell.org/~ghc/master/users- guide/bugs.h...](https://downloads.haskell.org/~ghc/master/users- guide/bugs.html) (Find 'prelude' in this page, has several appearances).

<comment><USER37> I didn't mean to imply all the prelude code was perfect. What I meant to imply was some parts are insofar as the specification is complete and specific enough that it yields one solution. An extreme example would be the id function.

</comment></comment></comment><comment><USER39> I hope this attitude is used sparingly and in cases where either the problem is supremely hard or where time is exceedingly short.

<comment><USER40> You are missing the point. "Good enough" depends entirely on the context. In some contexts, the bar for "good enough" will necessarily be quite high, while in other context it won't matter as much. There is no perfect code -- because no two humans could agree on such a definition.

Sure, people may disagree on what is good enough. But hopefully that disagreement will be easier to resolve than one about what the perfect solution might be.

<comment><USER39> My only concern is that this line of thought can be used as an excuse to stop trying. As long as we agree that one should strive for perfection given the constraints at hand (money / time / problem difficulty / experience level etc) I dont have any objection about the idea.

On a related note, I feel another analogous statement that I now see used dangerously is "Premature optimization is the root of all evil". Yes optimizing prematurely can be paralyzing but the other extreme where one refuses to do back of the envelope calculations and wilfully writes code that will be slow is damaging as well.

<comment><USER40> I can appreciate that. I have some perfectionist tendencies myself. I think it is a tricky balance that must we must walk. I like your idea of "as perfect as our constraints allow".

Another important consideration is the level at which the quality exceeds the needs of current and future users of the software. Past this point (which might be impossible to determine or fully agree upon), one must acknowledge they continue to iterate and polish for purely personal reasons. This can be fine in certain situations, but it may be a detriment in professional endeavors.

And of course, like always, one must consider opportunity costs.

</comment></comment></comment></comment><comment><USER41> Tooling is getting better. Ever looked at what Amazon does with formal methods to "prove correctness" for some of their systems?

Of course you can argue that "good enough" for them is "damn near perfect".

[http://cacm.acm.org/magazines/2015/4/184701-how-amazon- web-s...](http://cacm.acm.org/magazines/2015/4/184701-how-amazon-web-services- uses-formal-methods/abstract)

<comment><USER42> got a link to a non-paywalled source?

</comment></comment><comment><USER43> I [attended][1] a great lecture by [Alex Martelli][2] back in EuroPython 2013 titled "'Good Enough' is Good Enough!"

From the [summary][3]:

> Our culture's default assumption is that everybody should always be striving > for perfection – settling for anything less is seen as a regrettable > compromise. This is wrong in most software development situations: focus > instead on keeping the software simple, just "good enough", launch it early, > and iteratively improve, enhance, and re-factor it. This is how software > success is achieved!

[1]: [http://simongriffee.com/notebook/europython-2013-notes#goode...](http://simongriffee.com/notebook/europython-2013-notes#goodenough) "My notes. Biggest takeaway was to use 'perfect' as a verb rather than adjective."

[2]: [http://www.aleax.it/](http://www.aleax.it/) "Alex's homepage."

[3]: [https://ep2013.europython.eu/conference/talks/good-enough- is...](https://ep2013.europython.eu/conference/talks/good-enough-is-good- enough) "The lecture video is also on the page."

</comment><comment><USER44> I think that might be paraphrasing implications of Gödel's Incompleteness Theorem.

Non-trivial codes can either be consistent or complete, but not both (within a system of abstraction).

This explains Joel's "Leaky Abstractions" essay as well as the conjecture that code cannot be perfect.

However, "good enough" thinking is often just sloppy thinking. Even if mathematics has boundaries, it doesn't mean you just shrug and say "a nod is as good as a wink".

Craftsmanship and quality are perceived in terms of utility over time. "Good enough" often doesn't meet that bar.

Engineers overbuild to support capacity and plan for the worst. "Good enough" tends to under-build at or below capacity and hope for the best.

"Good enough" is a just reaction to over-engineering (the adding of unnecessary fixtures and 'perfection'), so the warning has value and there are some engineers who use it in this way.

But others often mistake over-building for over-engineering and cripple their organizations and products by seeking "good enough".

</comment><comment><USER45> Haha, there's some code of mine I've been regularly improving for 30 years now. Even versions I thought had attained perfection I rewrote later when I realized it was a POS.

The only software that is ever "done" is code that has been abandoned and is no longer in use.

</comment><comment><USER46> I try to follow this mantra from Kent Beck: "Make it work. Make it right. Make it fast."

I find that most of the development environments that I have worked in, the focus usually ends up being on getting new features completed in order to help facilitate the sales department to make sales. It's a never-ending cycle that will gradually accumulate technical debt such that pushing new features out the door will eventually come to a halt.

Yes, I agree that code can never truly be perfect. However, as developers we should always strive to make our code better.

</comment><comment><USER47> We should more than ever strive for perfect code. Perfect as defined by all stakeholders in a software. There is really no point in striving for anything less. Sure you maybe forced to stop at one point (time and money beeing the limiting factors) but if you can, you should always continue making software better!

"Good enough" is not good enough as a target. It's uninspiring and unsatisfying.

</comment><comment><USER48> I think the definition of perfect code depends on whether the computer is the end or the means. If it's the end, then there may never be perfection.

</comment><comment><USER49> Code is never "good enough", code is only ever "less in need of fixing than other code."

</comment><comment><USER50> Correction, code is at most "good enough".

I've seen (and written) plenty of code that was less than good enough.

</comment><comment><USER51> ...and, problems change even if the solution doesn't. At this point I only aim to build things that will durable and sensible for about four years. After that, some other change seems to come along that invalidates the original code, no matter how pretty it was.

</comment><comment><USER52> I'd love to see what YCs guidance on code quality is. My guess is "ship it if you get users".

<comment><USER53> "If the building isn't on fire you're not iterating fast enough"

</comment></comment><comment><USER54> reminds me of [http://algeri-wong.com/yishan/only-god-writes-perfect- code.h...](http://algeri-wong.com/yishan/only-god-writes-perfect-code.html)

<comment><USER33> Right on point. Furthermore, it just lead me to realisation that achieving software perfection is like reaching the speed of light: the closer you get to it, the heavier you are, and more effort is needed to go further.

</comment></comment><comment><USER55> ... like you could create anything and call it perfect. There is no perfect.

</comment><comment><USER56> Does the work of Charles Simonyi and intentional programming change this?

</comment><comment><USER57> Unless it is formally verified, then it is really perfect. Not sure why we shouldn't strive towards that final state of evolution. Conceding the game at "good enough" is a cop out.

<comment><USER58> Formal verification depends on frozen requirements. These are quite rare in practice.

</comment></comment><comment><USER59> And most of the time not even good enough.

</comment><comment><USER60> Insanity is doing the same thing over and over again and expecting a different result.

</comment><comment><USER61> ha the Dick and Bob bit is pretty darn funny</comment>


The myth of the pristine Amazon rainforest - <AUTHOR> https://www.mpg.de/11147178/amazon-rainforest-pre-columbian <comment><USER2> This article is an absurd misstatement of the research. Pretty much no-one is pushing the notion of a "pristine" pre-colonial Amazon. As the Nature article that also talks about this paper (both linked in another top level comment) points out, it's an open question "how much of an influence human activities have had on the Amazon" — not whether or not there's been an influence at all.

I've spent a lot of time in the Peruvian Amazon, and have talked (language limitations notwithstanding) with Shipibo-Conibo and Mestizo villagers about their relationships with the forest, specifically including their understanding of how that relationship might have been in the past.

That they engaged with it as both stewards and beneficiaries of its bounty should be a surprise to _precisely no-one_ who has paid the slightest bit of attention.

EDIT: Contrasting that pre-historical dynamic with the way many treat the forest today, having internalized Western economic values, is tragic. Clear- cutting; illegal logging; and slash-and burn, deplete, and move on to the next patch, are all examples of treating the forest as a resource, instead of as, for lack of a better word, a partner. And it shows. The place is slowly dying. Every time I go back, I can see more of the sand that lies mere inches under the staggeringly fecund topsoil blowing around, and getting into everything.

<comment><USER3> >Pretty much no-one is pushing the notion of a "pristine" pre-colonial Amazon.

Growing up I was taught the pre-colonial Amazon was pristine, and it has been only in recent years I have started to hear a different story. I bet most people in the US still believe the pristine idea.

<comment><USER2> I have no idea how old you are, but it's not at all surprising to me that a narrative like that is the one that propagates through the broader culture. Among other things, it speaks to how the enlightened Europeans brought civilization and what-not to the benighted savages of the New World. We like those narratives...

AFAIK, though, among the people who actually study this, or have cared to look into these matters for themselves (for whatever reason), that idea has no traction.

<comment><USER3> I generally agree with what you are saying. My problem was that when you said "nobody" I thought you meant people in general, not just the researchers in the field.

Furthermore, you seemed to be saying that articles like this shouldn't be published because people already know these facts. But I say they are good to publish because they help correct the views of the general public. Would you agree?

<comment><USER2> Oh, totally, there should be articles correcting the common notion, for the people who'd care enough to read them. This site didn't strike me as targeted at lay audiences, though.

</comment></comment></comment></comment></comment><comment><USER4> Here is a better summary from Nature: [http://www.nature.com/news/amazon- rainforest-was-shaped-by-a...](http://www.nature.com/news/amazon-rainforest- was-shaped-by-an-ancient-hunger-for-fruits-and-nuts-1.21576#/ref-link-2)

Here is the actual article (published on March 2nd): [http://science.sciencemag.org/content/355/6324/466](http://science.sciencemag.org/content/355/6324/466)

My takeaway: yes, humans _may have_ aided in the dispersal of useful plants across the Amazon in pre-Columbian times, but other factors were more important. The authors also did a poor job (as they acknowledge) separating pre-Columbian effects from those in more recent times.

</comment><comment><USER5> > _The myth of the pristine Amazon rainforest - Indigenous inhabitants shaped > the rainforest by domesticating tree species in pre-Columbian times_

That's not, as it's invariably used time and again, an excuse to do the same meddling with the rainforest now -- when we have 10,000 times their resources and effectives in killing the rainforest that these people had.

It's like people don't understand differences of scale...

<comment><USER6> "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" -Upton Sinclair

</comment></comment><comment><USER7> Recommended reading: 1491 by Charles C. Mann.

[https://en.wikipedia.org/wiki/1491:_New_Revelations_of_the_A...](https://en.wikipedia.org/wiki/1491:_New_Revelations_of_the_Americas_Before_Columbus)

<comment><USER8> Yes, plus one to this. I read it and found it be thought-provoking, and simultaneously incredibly sad and incredibly hopeful. It also really upended various preconceived notions, I, and I think a lot of people had about these civilizations, which has turned me into someone who rants about pre-Columbian civilizations at parties :).

</comment></comment><comment><USER9> Clearly someone (with deep pockets) needs to do a forest-as-infrastructure "startup".

I'm not kidding. If there are people who can make something like asteroid mining (Planetary Resources), this can totally be a thing...

...that's already sort of a thing (forestry), when you consider that's how tree farms work - only those are "optimized" for wood production.

Call it... "massively hetero-culture volumetric emergent agriculture", or something.

<comment><USER10> What I'd really like to see is autonomous drones that can harvest small berries, seeds, peas, leaves and root vegetables. You could develop permaculture gardens with extremely high yields and virtually no labour. The drones could even work to cultivate predatory insects such as ladybugs and wasps to keep pests under control.

<comment><USER11> That would be cool as hell. There's something oddly fascinating about autonomous drones flying around the wilderness harvesting/gathering resources, like some strange futuristic caricature of nature.

<comment><USER12> I think the wilderness should be primarily left completely alone with light- impact human leisure allowed in certain contexts.

I prefer the US public land approach where different lands are graded for different public uses, and certain areas are off-limits/prohibited to the general public because of practical concerns.

There is a 4300m mountain right by my hometown and while one can hike over much of the mountain and the range that surrounds it, certain areas are off- limits during seasons of the year because the mountain sheep drop and raise their lambs there.

Why not use your drones to turn your cities into gardens?

<comment><USER9> The article is almost about how the rainforests - long considered natural wonders of the world - are actually pretty heavily "engineered".

There is no doubt in my mind that, if we actually tried, we could make "batter" forests than "nature". More diversity, more vibrancy, more overall life.

A more local excellent example is the evidence that native north americans would do periodic burns, with many varied benefits for the different ecosystems that underwent such engineering.

</comment></comment></comment></comment></comment><comment><USER13> The title (which seems to imply that the destruction currently underway in the Amazon is no big deal, basically) is at odds with the text of the article itself, which takes pains to say:

 _The impact of the indigenous populations in Amazonia in pre-Columbian times can in no way be compared with the deforestation seen in the last decades. "Industrial utilisation has already destroyed one million square kilometres," Florian Wittmann says. The figure corresponds to three times the surface area of Germany and around 20 per cent of the entire Amazon rainforest. "It is of vital importance that we protect the remaining areas better," the scientist concludes._

</comment><comment><USER14> I saw this article awhile ago and was puzzled by it. Unknown ancient peoples planted productive trees thousands of years ago.

What does that mean with respect to the makeup of the forest thousands of years later? What does pristine even mean in this context?

</comment><comment><USER15> The first Western chronicle of Gaspar de Carvajal [1] spoke of large cities and well-paved roads in a region which is now "pristine" jungle. These chronicles were dismissed for a long time as fabrication, but it seems now there is a lot of evidence that Carvajal was speaking the truth.

[1] [https://en.wikipedia.org/wiki/Gaspar_de_Carvajal](https://en.wikipedia.org/wiki/Gaspar_de_Carvajal)</comment>


Turn Up the Volume with High-Speed Counters - <AUTHOR> http://blog.memsql.com/high-speed-counters/

<comment><USER2> Very nice!</comment>


Steps to Secure Your Freshly Installed WordPress - <AUTHOR> https://www.getastra.com/blog/securing-freshly-installed-wordpress/?utm_campaign=shareaholic&utm_medium=yc_hacker_news&utm_source=news <comment><USER2> Why do you need articles like this? Why is WP not secure by default?</comment>


Ask HN: Is it better to build intranet apps with desktop technologies? - <AUTHOR> In the recent "Electron is like Flash" thread it was claimed by many people that desktop apps are much easier to create and have better tooling than for the browser.
Is it a good idea to use desktop technologies for Intranet apps at least (with only API endpoints on the server)? Which stack would you recommend? How hard will it be to auto update the software?
Thanks. <comment><USER2> If your application needs to do some heavy lifting on the client machines, then yes desktop technologies will be better. Web browsers are sand boxed for security and can be too limited for some purposes.

Desktop applications can avoid security problems inherent in web apps that are run through a general purpose browser.

The commonly cited tradeoff with desktop apps is they are harder to deploy and update. I don't believe this is necessarily true. You can tell a desktop application to periodically check for updates and notify the user to restart before allowing further writes to any central data stores. If fact many already do this. Problems arise when the OS prevents updates from being applied by non-admin users and you are deploying within a locked down corporate environment.

Java SE/Swing is a good platform for writing cross platform desktop applications. I work on an engineering simulation tool with a complex UI written in Swing. With Nimbus Look and Feel it looks and works the same across Windows, Linux and OS X without changes. Some people (devs) complain that is doesn't look native - none of my users care though.

The few times I have ventured into web development I have been horrified by the amount of work required to get web apps to look and work the same across different browsers. JQuery and Bootstrap deal with a lot of the pain but web dev still feels very hacked-together compared to desktop development to me.

</comment><comment><USER3> My rule nowadays is to go with a web application unless you have a good reason not to. The difference between the work done for deployment is enormous, and it's enough to justify avoiding desktop applications 90% of the time.

<comment><USER4> For a lot of apps, this works, but I think this is also what's led to number of Electron packaged apps.

It starts out as a web app, because you can iterate quickly and its mostly platform agnostic. Then people realise that what you're doing means a 'dedicated' app is a better experience.

At this point, the correct choice would be to have someone create a desktop app that uses your existing web app as an API. If your web stack handles accepts/content-type switching in a decent way, this may mean very little or no work on the backend.

Unfortunately this is also the point where its become common to adopt Electron. Like a lot of things that are wrong in this industry, I blame it on the cool kid javascript/front end developers. "Oh sure I can just make you an electron app for desktop users, its just js/html/css".

<comment><USER5> "The correct choice" was only correct after the application was created and iterated upon and somewhat widely adopted. Would any of the rapid feature iteration and widespread adoption have happened if this theoretical application was _initially_ created as a native app?

<comment><USER6> > Would any of the rapid feature iteration and widespread adoption have > happened if this theoretical application was _initially_ created as a native > app?

Yes. Desktop applications can be just as quick to develop and iterate on as web based ones. Slapping together a winforms UI in visual studio is still the quickest way to get to MVP status.

<comment><USER7> But how do you manage deployment of a new version? That's where the web comes into its own.

<comment><USER6> Deployment is definitely harder, but not to the point where it's unmanageable. Click once is one solution that's very common, though not great. It will check a url for a new version at startup and install that version. This URL can be a simple aspx page that gives each user the right version, I recently automated this as part of our CI deployment.

A better solution would be something like chocolatey ([https://chocolatey.org/](https://chocolatey.org/)), which is basically a package manager for windows. It doesn't do the automatic updating, but doing that with a remote powershell script should be doable.

For some perspective though, if you automate this as part of a CI builds it should be a once off cost, it's not a justification to make something a web app instead.

</comment></comment></comment></comment></comment></comment><comment><USER8> I don't think so anymore, though I would have said yes even a few years ago.

I see most of the companies I work with moving towards AWS or Azure with all the scaling support and APIs that really make web apps easier to work with.

Instead of dealing with dozens of IT rules as to what can be installed on the various corporate images (which now include Macs), it's easier to just point users at a URL and make sure whatever single sign on they've got is integrated.

Another point: desktop apps are just as complicated as web apps these days, especially when dealing with Mac, Unix, Windows compatibility along with mobile. It seems like nobody has really done a good job of replacing VB6, Delphi, etc, and I haven't touched (as a Java developer) Swing or JavaFX in years.

</comment><comment><USER9> Web apps are great for most intranet apps. Especially if you already have a single sign on solution. Deployment and maintenance are easier, as is replacing the thing when it becomes obsolete. With a desktop app, once it's out there, it's out there with all the headaches that brings. Otherwise, hard to make a recommendation without any specifics.

</comment><comment><USER6> It's a good idea to use desktop technologies if the app is complex, for most corporate intranets a few web pages is probably good enough.

As for the stack, c# and winforms is a good bet, particularly if you need to target older versions of windows. If you need a bit more performance or cross platform support then c++ and qt would be better. You could go c++ and win32, but MS dropped the ball on creating a nice api.

Deployments are another area MS dropped the ball, click once is sort of ok if you are using visual studio, but either way chocolatey is better. You may want something better for release management, in which case look into octopus deploy. These suggestions apply to electron apps as well.

Basically, had windows XP come with a better programming APIs (more like qt/gtk) and a better deployment model then web apps would have never been a thing. OSS has made windows a viable desktop.

<comment><USER5> Why bother with bad apis and hacky deployments? I'd venture to say the answer to OP's question is a simple "no".

<comment><USER6> Because I don't have utter contempt for the users of my software and a little bit of once off pain for me (like fiddling with click once deployments) is worth if it the product is better for 1000 people that use it everyday.

It's simply a matter of what those variables are. A sick leave application form that get's used a few times a year? Stick that on the web, the installation cost isn't worth it. A productivity tool that's used all day, every day by a lot of people? Make that a desktop application, especially if you need local resources, like files. An application used by millions world wide everyday? Write that in a natively compiled language and use the native (or decent cross platform) UI, there's no reason your productivity is more important than the millions of users.

</comment></comment></comment><comment><USER10> Thanks for your answers!</comment>


Facebook isn't necessary - <AUTHOR> http://chrbutler.com/facebook-isnt-necessary <comment><USER2> I logged out of facebook a few weeks ago with the intention of never going back. I got to say it's a deeply liberating feeling. Once you realize that people just go there to go there, breaking that loop is incredibly gratifying.

On the other hand, I still use FB messenger as the main means of communication for almost all of my friends abroad.

<comment><USER3> I unfollowed everyone so I don't have a news feed anymore. I'm not missing anything.

<comment><USER4> done this too followed later by deleting account because what's the point after all

as for never who want to contact me feel free to use signal, sms, email or calls, also running Skype Mingo for few other people

</comment></comment></comment><comment><USER5> Facebook solves one stupidly important problem: it's an easy digital index of everyone I'll ever meet. I treat it more like the yellowpages than a social network and as a result never really have a reason to think about it.

</comment><comment><USER6> Facebook UI and UX is comically bad, it's just that currently FB holds the "network effect" for a generic social platform on the web. And yet the site still functions like some relic of an AOL landing page.

I can only assume most people must be uninspired, or unaware of how to seek out alternative forums on the web.

</comment><comment><USER7> [Meta] I clicked the link. Saw just a white screen. May have had some light grey markings but my eyes couldn't tell what those markings could have meant.

<comment><USER8> Serious accessibility concerns on that site. Unreadable on most mobile browsers. At least on desktop I have 'reading mode' and 'color invert' extensions. Plus, what is up with that incredibly thin font? I've only ever seen that use for a sub-headline on a product landing page. Never as the body text font.

</comment></comment><comment><USER9> Interesting point about the difficulty of removing fake news:

>> On Wikipedia, you have the freedom to set up an account, log in, and edit any entry you like. You can change the name of George Washington to Billy-Bob Washypants if you like. You can say he's still alive and sells insurance in New Jersey. You can say he has sixteen cats and has gone vegan. Whatever. Will your edits stick? No. That's the point. The openness of Wikipedia is the outworking of a philosophy that truth, when crowdsourced, is just as strong — if not stronger — than when managed by a select few. Now, one too many bogus edits and you'll be banned from Wikipedia, which is, again, in line with their philosophy. If your intent toward information is chaotic-evil, fine, but you're not entitled to go about your trickster ways anywhere you like, and Wikipedia is entitled to kick you out. So how about Facebook? On Facebook, only the original creator of a post on Facebook can edit it. The crowd has no recourse but to complain to Facebook, and Facebook, of course, has already said that the content isn't their problem.

<comment><USER10> >The openness of Wikipedia is the outworking of a philosophy that truth, when crowdsourced, is just as strong — if not stronger — than when managed by a select few.

Unfortunately Wikipedia isn't like this in practice. There are several articles written in a quite biased way, with biased references, which are then locked at various thresholds. Wikipedia, just as the democracy it relies on, is no truth machine.

<comment><AUTHOR> Interesting. I'd love to learn more about that. What do you mean by "locked"?

</comment></comment></comment><comment><USER11> This is extremely meta and only tangently on topic.

I don't use Facebook and live in SV (Redwood City). I have lived in many places but have never had so much trouble maintaining meaningful connections as here.

If someone local would like to meet up for coffee only on the basis that we both read HN and neither use Facebook, I would be interested to meet you and share stories. I've temporarily put my email in my profile.

</comment><comment><USER12> I removed myself from FB around 2 months ago. It wasn't anything special, didn't notice anything lacking from my day-to-day life whatsoever. Also didn't notice any "liberated" feeling or anything like that as well.

</comment><comment><USER13> I found that Facebook lost all relevance and provided really... nothing to me, my life, my friends or my family around about 3 years ago. I'm not one of those elitist 'I quite facebook' people but, I did and my life did improve, and guess what? It wasn't social media or the distraction that was the problem - it was the medium. Since then my twitter usage has grown like crazy and I absolutely love it, I learn things, I laugh, I ignore some things but over all - I really love the platform.

</comment><comment><USER14> Facebook is a great tool for many uses.

The most empowering thing I can personally think of, it lets small organizations/businesses reach a lot of people without spenind any money. Anyone who can't afford a website can still put content out there and reach their audience.

It's great for advertisers. While with AdWords from my experience clicks rarely convert, Facebook works generally well.

Like Whatsapp, Messenger is an awesome free chat that most people will have already installed and that makes communicating with new people extremely easy.

People who complain about Facebook seem to be those who use it improperly, such as not being able to ignore notifications for more than 30 seconds, or sharing private things irresponsibly.

<comment><USER15> As an organization, you can't actually reach "your followers" on Facebook for free, because they aren't your followers. Facebook will lower and lower the reach of your posts until none of your audience actually sees them. They'll gladly show your posts to more of your audience for a fee though, which is where much of their advertising revenue comes from.

Any small organization/business would be better off with an email list, so they can actually contact their audience.

<comment><USER14> A small store or organization can tell their clients: "pictures of the products are on our Facebook page, check them out".

I've been trying to adopt a dog, and all shelters have a Facebook page where you can see the dogs. They wouln't have the money for building and keeping a website updated.

</comment></comment></comment><comment><USER16> Obviously the quality of the internet as well as interpersonal communications was declining already before Facebook came along.

Facebook isn't necessary for this decline to occur, but it does accelerate the process.

disclaimer: didn't read the article

</comment><comment><USER17> I have seen a couple of news on communal violence (resulted in death) originating from a facebook post, is there any statistics on that?</comment>


Ask HN: Salary stipulations attached to seed deals? - <AUTHOR>

This is something I have been wondering about. Say you are an unmonetized company and you take a $1mm seed round. Your company may be unmonetized, but if you are working full time, you need to pay yourself to live. Generally speaking, who decides the amount of your salary?
Is this a stipulation that goes into term sheets? Is it based on labor market value? e.g. if you're a software engineer, you pay yourself max $100k?
Just wondering how this works. <comment><USER2> In a seed round, you presumably don't have your investors on the board, so the answer is ultimately you set your salary. I might have an information right as an investor to certain financial docs which would let me figure out the number for founders I invested in, and I'm positive they'd just tell me if I asked nicely, but I don't recall any formalization in the docs about it. (Sample size: 2.)

Common practice is to pay oneself substantially below market, with higher salaries for entrepreneurs with higher personal expenses, which usually translates to "married plus kids plus house equals a lot more money." I'm unsure common practice is either fair, wise, or optimal, but not strongly committed to that that. (I do think strong pushback on any reasonable founder salary is a disqualifyier for investors that I'd take money from or advise taking it from.)

This answer is modestly more complicated after you have a board, presumably after series A.

<comment><AUTHOR> So basically investors want to know that you are not taking investment because "doing a startup" pays better than your market-rate job. It's a motivation filter.

Below market salaries motivate founders to generate profit. Since investors know they have legally little control over the founders, any motivation increases investment value.

</comment></comment><comment><USER3> The board of directors decides.</comment>


GitHub vs. Resume: Why Bother with a Resume in the Age of GitHub? - <AUTHOR> https://blog.kickresume.com/2017/09/11/github-vs-resume/ <comment><USER2> > Why Bother with a Resume in the Age of GitHub?

1) Because not all experience can be public visible code

2) Because recruiters, who are often firewalls for candidates, can't import a GitHub account into their MS Word doc keyword scanners

</comment><comment><USER3> Because I've worked at a lot of companies and gone through a lot of interviews and NEVER has anyone said anything about my or anyone's github profile, whether interviewing or hiring (other than me, but my coworkers and interviewers have cared less).</comment>


Why Silicon Valley Is So Nervous About H-1B Reform - <AUTHOR> http://www.forbes.com/sites/mattdrange/2017/02/03/why-silicon-valley-is-so-nervous-about-h-1b-reform/#309bafe46648 <comment><USER2> 70-80% of H-1Bs are migrant server coolie workers for ultra-cheap mass labor camp shops. The Silicon Valley companies see the entire quota eaten up by those el cheapo slave drivers.

With a real salary floor, the qualified engineers that serious companies want to import will find it much easier to obtain spots under the quota. The low wage cheaters will be cut out of the lottery and productive businesses will get those slots instead.

It's probably the best thing that could happen to companies that want to import actual qualified smart engineers from overseas.

<comment><USER3> Which is why I'm left wondering, why is it that "Silicon Valley Is So Nervous About H-1B Reform". Unless the headline is simply clickbait, I don't think the question was answered...

<comment><USER4> What the article was moving towards - but never actually said - is that there is a fear that reform will "throw the baby out with the bathwater". For example rather than fixing the rules so that spots go to the right people, changes may just reduce the overall number of visas.

<comment><USER5> Given the approach to the new administration, seems like the generic solution will be to just reduce the number of visas (ahem after revoking 100,000 of them).

</comment></comment></comment></comment><comment><AUTHOR> Indian IT companies need to stop using H1-B visas: Narayana Murthy [1]

He said " Our managers will have to learn with non-Indian professionals, how to get the best out of them, how to work in teams that are multi-cultural, how to make sure that we understand the rules of crossing cultures,"

\--

I see this as "Its hard to find slaves from other-countries. I know lot of Indian IT professionals _hate_ their managers. Because they treat them as 'slaves' and force them to work for +9 hrs day regardless of work is there or not. I bet his (Infy or others body-shopping) managers can't do the same to non-Indians"

[1] [http://www.livemint.com/Industry/VtFnghv7Wqu6r5J7M9n3EN/Indi...](http://www.livemint.com/Industry/VtFnghv7Wqu6r5J7M9n3EN/Indian- IT-companies-need-to-stop-using-H1B-visas-Narayana.html)

<comment><USER6> > I bet his (Infy or others body-shopping) managers can't do the same to non- > Indians

The root cause is not their nationality, but their immigrant status. With a setup where the employee's stay in the country is tied to her job, abuse will always happen.

<comment><AUTHOR> I agree on the immigrant status point of view. But when the abuse happens in their own (India) country too. I suspect there is much larger problem - mindset of IT Managers.

</comment></comment></comment><comment><USER7> A lot of the diversity data that companies have put together recently doesn't show the magnitude to which companies depend on non-citizen labor.

<comment><USER8> most of them are coming in as contractors via 1099. The Customer (Amazon, Microsft et al) see it as an invoice and may be paying a market rate, but the H1-B sees very little on the W2.

I have witnessed two companies simply cut an entire IT Department (The Run, or Support Org) and insource/outsource it.

</comment></comment><comment><USER9> Too bad the ultimate client for these "body shops" isn't listed. Would bet that's heavily represented by those in the fortune 500. I can think of at least one company in the top 10 that is not going to benefit from paying a rate that will support 130k/yr salaries.

</comment><comment><USER10> Why does Infosys and others employ so many in the U.S.? That $70k they pay per developer could probably cover several in India!

<comment><USER11> It might help a bit to explain their business model.

Infosys (and similar companies) flood the H1-B lottery system with tens of thousands of applications. They bring those who win to the U.S. where Infosys contracts them to U.S. companies in development, onsite techsupport/IT, and various lower cost roles. U.S. companies pay Infosys a premium to contract these employees.

Infosys is in the market of selling people. They are gaming the system, and making it harder for high paid talent at Google/FB/Apple to get H1-Bs.

</comment></comment><comment><USER12> If money isn't an issue, then surely they won't mind a higher salary requirement. $130k is reasonable for the greatest tech talent in the world, right?

<comment><USER13> Actually, the top companies in the Bay Area are paying _dramatically_ more than $130k, so they wouldn't mind.

<comment><USER14> That was my immediate thought when I heard about this. Raise it up to at least 250k if you really want it to get back to being a program for the truly unreplaceable talent.</comment></comment></comment>


Racket v6.2 - <AUTHOR> https://groups.google.com/forum/#!topic/racket-users/AOnzfwcYyV0 <comment><USER2> The best CS course I took was "Designing Functional Programs", an introductory course at Waterloo.

Haskell is used as the pseudo-code for lectures while assignments are written in Racket.

The course was great because the professor (PR) was:

1- Passionate

2- Knowledgeable

3- A kind person

I have found Racket to be a very effective way to make students (most of them have either no CS background or only have played around with imperative/OOP languages) more comfortable with functional programming.

The best memory I have was during the first lecture. After all the administrative fluff, the prof open his pdf and the first slide reads: "Induction"

I remember thinking "Is this a maths or a CS course?"

The second slide defined the set of natural numbers. As the prof start explaining the syntax and its meaning, I slowly start to realize the beauty of those few words:

Data Nat = Z | S Nat

where Z represent 0 and S the successor function.

We define the data type "Nat" to be either zero or the successor function applied to a "Nat".

It was my "ahah" moment. I was mind-blown by the language's clear syntax and immensely powerful semantics. (This is Haskell not Scheme/Racket).

We would later be introduced to lambda calculus (untyped vs typed), infinite data structures, interpreters etc... It was glorious... What a great professor.

The only "downside" to this is that Racket/Scheme isn't very much used outside of Academia. Which is clearly a shame given its incredible built-in features and elegant LISP-like syntax.

Should anyone have insights/opinions on why Racket/Scheme aren't more used, please feel free to share them with us!

<comment><USER3> Re: why racket isn't used more

Last time I did some json parsing it was poetry slow. I've also heard the continuation based webserver was slow and uses a lot of memory.

I'll have to benchmark again to be sure. I hope I'm wrong, racket was very enjoyable to use.

<comment><USER4> There is a simple solution: Don't use continuation. Write your web-app in the same way you would in Python or similar.

See "Low-level web programming in Racket + a wiki in 500 lines" by Matt Might:

[http://matt.might.net/articles/low-level-web-in- racket/](http://matt.might.net/articles/low-level-web-in-racket/)

<comment><USER3> I saw this and it made me very happy. I was going to mention it in my original comment but I couldn't remember the link. I'm going to put this in my "tutorial TODO" list, it looks like a lot of fun! Thanks :)

</comment></comment></comment></comment><comment><USER5> I'd just love to see this work well with a proper SCIP plugin on Windows. MIT/GNU Scheme sort of works on Windows, but you can't integrate it with EMACS. Dr. Racket comes closer, but the libraries have been moved from (or to, I don't remember off hand) Planet, and trying to get them installed is painful and prone to error. It becomes really difficult to study the lectures without a good environment and Dr. Racket is the most promising because it supports graphical output. I just wish it worked properly.

<comment><USER6> I got a fair way through SICP using DrScheme (now DrRacket) a few years ago without any special compatibility modes, and found the set-up to be pretty great.

Now there's better compatibility thanks to

#lang planet neil/sicp

[http://www.neilvandyke.org/racket-sicp/](http://www.neilvandyke.org/racket- sicp/)

<comment><USER5> That's what I've had such a hard time setting up. The newer Dr. Racket uses a different library system and last time I tried to get things working (on 6.1 I think) it has all sorts of problems downloading. I had to use older versions and it was never installed correctly.</comment></comment></comment>


College as We Know It Coming to an End? Don't Bet on It - <AUTHOR> https://www.bloomberg.com/news/articles/2020-05-22/college-students-parents-professors-hate-online-classes <comment><USER2> Naivety and Luddism shared between students who've digested an idyllic aesthetic of what college should be like(sold to them), and professors too busy being mice in the game having a creative-void and reduced to merely drone librarians all caught up in the rusting high-education landscape. Seriously? They don't want to use 21st-century tech in novel ways, or put demands for platforms provided by companies to go beyond and help offer an experience that could bring virtualization and steep use in a way to make pedagogic methods for this new century? No, instead they want to be (maybe un)witting drones in the cycle of rising tuition and a pedagogical stagnation?

I'm not suggesting the end to all physical spaces, as labs are still needed and for more than just STEM, but for lecture, for theory, come on, no one wants to use technology? A very cynical perspective is that not only may some professors have no imagination but that it threatens to transform the revenue stream in a way alien to the incumbency.</comment>


YCRFS 2: New Paths Through Product Space - <AUTHOR> http://ycombinator.com/rfs2.html

<comment><USER2> Shopping is broken, by Scott Adams:

Let's say you have a problem or a need or a want, and you're sure there is product somewhere in the marketplace that would help. You Google, and a handful of web sites pop up that offer promising solutions. But obviously you don't believe anything you read from vendors, so you check for online reviews. Then you wonder if the favorable reviews are planted by the vendor, and the bad reviews are planted by his competitors. Can you trust reviews from anonymous strangers?

You ask your coworkers and friends if they have ever used the product that you're interested in, and no one has. What now?

Shopping is broken.

How much more stimulated would the economy be if the people who have money, and are willing to spend it, could be reliably connected with the products that they desire?

What the world really needs is some way to connect you with the people who already use the sorts of products you want, and are willing to answer an e-mail or two about the topic.

About a year ago I had surgery to fix my voice. The information on the Internet about that particular surgery was outdated and didn't address my questions. The only way I could become a consumer of that surgery was by communicating directly with people who already had it, which I did. And since then I have answered questions for dozens of people who have the same questions that I had.

Likewise, as my wife and I make a zillion decisions for the home we are building, we prefer products and solutions used by people that we have spoken to personally. The Internet is virtually useless for any of the hundreds of product decisions we have made so far.

And what about choosing a destination for a vacation? You're much more comfortable if you have spoken to someone who visited the same place.

The obvious problem with connecting past consumers with potential consumers is that while people are generally helpful by nature, no one wants a million e-mails asking how they like their new can opener. So how do you strike the right balance?

Imagine a system that works like this: When you buy a product, you agree in advance to answer up to four e-mails from future potential customers, beginning no sooner than one year from when you make your purchase. It's totally optional, but agreeing gives you access to people who already bought the product you're considering today, to help you make your own decision. It would strike you as a fair deal.

For privacy reasons, this imagined system would disguise your e-mail address. And the system would have to be administered by some third party, not the vendor selling the product, or you wouldn't trust the strangers giving you advice.

Maybe you have a better idea for fixing shopping."

From: <http://www.dilbert.com/blog/entry/shopping_is_broken/>

<comment><USER3> Interesting, but I still don't see how the fundamental trust issue is covered by the proposed solution. The system may reduce the chance that a reviewer is a shill, but it in no way establishes their credentials. All you know is that they purchased the product - and frankly this already suggests a level of bias.

People will continue to value the advice of those they know much more highly. The challenge is to establish a comparable level of trustworthiness in online reviews.

<comment><USER4> You have to build a trustworthy, independent brand.

To be honest, really freakin' good graphic design goes a long way.

</comment></comment></comment><comment><USER4> What would be best paths through product space?

My first thought was "doesn't Amazon already organize things independent of vendor?" But what we're really looking for here is a recommendation engine, and Amazon really isn't very good at that. As I see it there are three main steps which should be done in order. The more you know about ahead of time, the further you can skip ahead. Here are the steps:

Step 1. I don't know what I'm looking for.

Maybe I'm looking for a good science fiction book. Or a gift for a 14-year-old niece. A deep gift recommendation engine alone could probably make a good startup. The engine should ask some probing questions and give recommendations—either specific products or product categories, depending on the type of question. This experience mimic the experience of having an experienced salesperson ask questions and point you towards good options. A beautiful browsing option would be a great way to conclude this step.

Step 2. I know what I want, but I haven't decided which brand or model to get.

Here we need a deep comparison. The ability to rank priorities would be really helpful. Let's say I'm buying a laptop. The site should ask me how much I care about weight, screen size, processing power, etc. It can then recommend models that fit within my budget. There's a huge amount of domain-specific knowledge required to get this right for a variety of products.

Step 3. I know what product I want.

Here we need to give comparisons among vendors. Price, shipping speed, return policies, and other general customer feedback are important. This is where it helps to be a trusted third party.

This problem is a huge undertaking, which is why no one has come close to solving it yet. Frankly, unless the domain is very restricted, I don't think a three person team will be able to do enough specific programming and testing to make it work.

The principles and mechanics would best be discovered in a very narrow marketplace, and one full of confusion. Electronics would be the natural stating place, but a less crowded market might also work.

<comment><USER5> The problem with steps 2 and 3 is that most of the time people aren't really sure they know what they want. They may have narrowed things down to a category, such as laptops as you mentioned, but even then you'd be hard pressed to find someone that absolutely KNOWS they want a laptop. Maybe a netbook + desktop would be a better combo? Or an iMac-style nettop. Furthermore, at any given time people are usually in the market for more than one thing, all at various stages of the buying cycle.

So now if we can simplify and treat all cases as "I don't know what I'm looking for" then follow-up to that is "I'm looking".

In that case the experience can be optimized around the looking and searching. I think the key concept in searching is, unsurprisingly, speed. Let me look at a lot of products quickly, let me research an individual product quickly, jump back out quickly, jump between categories, jump between different lists, sorts, filters, etc.

And I think pg is missing something, as the path doesn't end when a product purchase is made. You have all the nitty gritty of the actual transaction + shipping, but then you have post-purchase life as well. Most stores have you buy the product and then have you go somewhere else for support. Sure you can review the product on the store, but what if you want to hack it? or you have a problem? or you want to upgrade? etc etc. Is it up to the manufacturer at that point? What if you can't find the manufacturer's support resources?

We're doing some interesting things here at ProductWiki, but our goal is to create a great base of content and data. I imagine that one day a company will take the open data to create a really nice and innovative shopping experience.

<comment><USER4> You're totally right. Guiding people in the choice between even just the various computing options is a major task. This is just a big, big nut to try to crack..

To anyone attempting it, I'd suggest again starting in a very tightly focused domain. My pick would be cameras -- the classic "whattheheckdoIwanttobuyIhavenoideawhatthesenumbersmean" product.

</comment></comment></comment><comment><USER6> _"Online stores group products by who sells them."_

Do you really find this to be true?

1) Go to <http://www.newegg.com> \-- while brand/vendor is one selection criteria, so are many of the technical specs and options. They even offer advanced and power search.

2) Amazon is no different: While Brands are promoted (because consumers are trained to that) they offer power on the left side here (below brand): [http://www.amazon.com/Digital-Cameras- Photo/b/ref=sv_p_4?ie=...](http://www.amazon.com/Digital-Cameras- Photo/b/ref=sv_p_4?ie=UTF8&node=330405011)

While I don't think that the statement in the RFS is accurate, there is no doubt in my mind that the online product finding experience has dramatic room for improvement and innovation.

<comment><USER7> I think PG's point is that NewEgg only lists products sold by NewEgg. Amazon is a little different since they have affiliated retailers, but they still don't have _everything_.

<comment><USER6> Having everything is not what I want.

I go to Fry's for fun things, Banana Republic for work clothes and Neiman Marcus for gifts for the girls who care about those sorts of gifts.

No website will ever give me all three in a sane format; nor do I care for it to do that. Nor does my mother.

</comment></comment></comment><comment><USER8> _Online stores group products by who sells them._

One of the challenges of abstracting this layer is that _who_ sells the product still adds or subtracts value from the purchasing experience because of those mundane details (shipping speed, reliability, returns, etc.).

There are various ways of dealing with this. Amazon [1] is already active in this space using what you might call the "user review" model combined with enforcing some exacting standards on their vendors. Already having a huge channel of course made it easier for Amazon to get vendors to accept this.

[1] Incidentally, I've never thought that Amazon did a great job with sorting products within its general categories, so I always search instead. But I do wonder, how many more people would window-shop at Amazon if their sorted product catalog was more interesting?

</comment><comment><USER9> This sounds interesting. On a very high level, a good solution to this would feel like window-shopping in a huge mall. Amazon.com is great if you know what you're looking for, (as GavinB said), but it's doesn't work for discovery. I can't meander through Amazon.com to check out products and I wouldn't go there for fun. Compare that to your local mall, where people go to just hang out.

Shopping is often a pass time and a social experience, not a mission, yet most sites are optimized for the last "stage" of shopping--the stage where you actually make a purchase, or the penultimate stage--the one where you compare a few specific products. The last stages are the most profitable and easiest to implement, so that's why they came about first. But if you can grab a consumer at an earlier stage, when they're brainstorming bridal shower ideas, or when they're bored at work and checking out new cell phones, and if you optimize for discovery as well as sales, they'll come back and buy from you.

The challenges/pitfalls/competitors are numerous, obvious, and non-obvious. Good luck to the team that attempts this!

</comment><comment><USER10> Community Driven Web Shopping

Internet tends to be an open system where consumers are in the same way important as the product makers and sellers. Success is measured by community support and it is assured by complete transparency, trust.

Marketing your online products also cannot be done well without a strong community. A future webshop must be completely user and community driven, your duty as a webshop owner is to build trust and make your existing customers to connect to your next customers.

A Classic Store vs. Auction Based Stores

Following years will be about a 180 grades shift in e-commerce. Now you are presenting products to customers as a classic store, later customers will ask you for products and services.

Yabe.hu -- Race. For you -- is a new approach to shopping. As a customer you log in and tell your desires then vendors are racing to offer you the best solution. This is the only way to assure yourself you'll get the best deal.

You don't have to choose, listen to commercials, browse social shopping sites and do research to find what you want; just spit out a desire and let the others do the job for you.

Until this approach to shopping hits mainstream you'll have to do the classic way. Look for a shop who makes you feel comfortable, do the shopping, show your items bought and generate trust for other users and would-be-customers. Wait for your cut offered by the webshop as an affiliate program.

A Classic Webshop In Modern Clothes

       1. Browse to your favorite online (gadget) store.
       2. You are sure the frontpage is already taylored to your shopping needs (via an Automated Recommendation Engine)
       3. Select your products to be bought and check for the best price gathered from other (gadget) stores.
       4. Make shopping and later add comments, recommendations, how-to's, FAQs to your products bought.
       5. Other users will see your value added to existing products and when buying you'll get a fair cut from every sales.
       6. Too boost your revenues use widgets with your products bought on your blog or favorite social network, do the marketing and sales for the webshop you like and which pays back your efforts.

</comment><comment><USER11> There's also the question of "how do you arrange the products in order to maximize profit". There's also a great deal of machine/learning data mining that could be involved in this: e.g. market/basket analysis ("people who bought product X, also bought product Y"). Safeway does this, Amazon does this.

<http://en.wikipedia.org/wiki/Affinity_analysis>

That would make this an ideal project for people with machine learning/data mining experience, particularly from a retail/e-commerce background (Amazon, eBay, Wallmart.com or even a brick and mortar store chain such as Safeway).

</comment><comment><USER12> It seems to me that a great interface for presenting products would almost necessarily have to be individually designed for each store. I don't see how you could use the same kind of interface to present, say, books and perfume.

Also, I have a hard time imagining how big stores could choose to use a presentation system similar to that of other stores. Unless I misunderstood the original idea, it seems that selling presentation software is not the right way to address that problem.

</comment><comment><USER13> So, basically FriendFeed for the consumer-facing part of online retail?

Having a good understanding of co-op advertising could matter a great deal here. Retailers get paid by manufacturers for product placements... Someone going after this model could try to reach similar deals with both the manufacturers and the retail-fulfillment entities.

</comment><comment><USER14> Etsy is a fanciful/artistic version of this RFS.

<http://www.etsy.com/>

</comment><comment><USER15> Why does it have to be a storefront? I think it would be better if it were an advertising solution.

</comment><comment><USER16> sounds like guided navigation, faceted search and relational database stuff.

</comment><comment><USER17> _...the companies that were best at mundane things like answering questions, taking orders, packing and shipping them, and taking returns..._

The companies that are best at these things are best precisely because they don't consider them to be "mundane".

In customer service and fulfillment, it's a fine line between being excellent and being out of business. These can be very difficult things to do, and the thinner your margins, the better you have to be.

And very few companies handle customer returns well. They keep getting better and better until they realize the best way to handle customer returns is to avoid them in the first place.</comment>