Web designers should start companies, not freelance - <AUTHOR> http://jaequery.tumblr.com/post/12480331305/web-designers-should-start-companies-not-freelance

<comment><USER2> >a rockstar designer should take more stake in a company than a >rockstar developer.

That made me laugh. I imagine the post was written by a designer.

I understand how important design is, it's _as_ important as the backend. But somehow the OP believes that it's only the design that made some apps successful. He also undermines the countless sleepless nights the "engineers" at Apple spent trying to make things work to fit the design. Without fair share of both, it's impossible to make a product successful.

>A web site can be as clunky as it can be in terms of back-end >but if the front-end kicks ass,

The OP also makes the mistake of thinking, that design is only buttons and borders. Front is a fairly delicate balance of UX, UI. Without an appropriately "designed" backend which is equally responsive, all falls apart.

<comment><USER3> Design can be split-tested by someone with average skills and end up with above average results. The same is not true of development. Throwing together a bunch of things and trying them in production leads to unmaintainable code and many hard to track down bugs. One requires time and persistence, the other requires knowledge, planning and problem solving.

<comment><USER2> >Design can be split-tested by someone with average skills and end up with above average results.

I do think split testing is not the answer in every case. Firstly you have to know what to split test. A product like Dropbox cannot be designed just by split testing for example. See MS Windows file copy as an example, i still think it's broken.

With dropbox, somebody noticed a problem and wanted the product to be so easy to use, even to the extent of being invisible. I would imagine split testing would lead to dozen tabs of configuration of file sync rules.

</comment></comment></comment><comment><USER4> " _A web site can be as clunky as it can be in terms of back-end but if the front-end kicks ass, people can easily overlook the back-end. But the same is not so true in reverse, which is to say, no one gives a crap about the "back- end", as long as it works._ "

weakest argument ever, and the whole post stands on it.

<comment><USER5> In other fields, that's called a marketing gimmick (some would go far by calling it a scam).

</comment></comment><comment><USER6> As a designer who's launching his own business (<http://folyo.me>), I can certainly identify with this.

But I also know that it's easy to be blinded by the new entrepreneur's enthusiasm and see the world through rose-colored glasses. Whether you're a designer or developer, starting your own company or project is not for everybody and has numerous downsides.

For example since launching Folyo, I've spent almost no time on actual design. Instead, I'm spending most of my time either coding (I've learnt Rails) or writing on the blog (<http://blog.folyo.me>) to try and drive some traffic to the site.

I also didn't take on any new client projects, which means I've missed a couple nice opportunities, and also made much less money in the past couple months than I usually would.

If you're a designer and you want to stop freelancing while staying independent, I would instead advise that you sell Wordpress themes, sell icon packs, or maybe write an ebook.

Starting a company is definitely not the easy way out, and is not for everybody.

<comment><USER7> I wonder if there's a market for a kind of paid mentorship, for developers looking to improve their design.. A few emails a week and one or two face to face meetings / Skype sessions ...

"wow.. You really need to work on typography.. Let's look at these examples .. I'll send you some homework. Now let's talk about the color theory you went through this week.."

</comment></comment><comment><USER8> I don't know if web designers should start companies or freelance, but this article didn't do anything to cement my opinion on the matter.

He starts out with a message to startup founders about how design will singlehandedly bring your site to prominence. He doesn't present any evidence for this.

He posits that designers don't get involved in startups because they believe their services aren't all that valuable. I think this is a rather unrealistic view of the situation. If anything, designers are prone to exaggerate their contribution to a project in my experience. I would suggest the reason designers don't get involved in startups is because they've dealt with enough nutty entrepreneurs to treat the field with skepticism. This is a realistic view — most startups simply aren't profitable ventures.

He then concludes that designers should get involved with startups because they're simply more satisfying than freelancing. This seems like such a subjective point that it's not even worth mentioning.

He never does directly address the claim in the headline, that designers should start startups.

</comment><comment><USER9> Allthough I give this guy a credit for praising often neglected designers, he is in no way entitled to bash on engineers and say that they are less valuable. A good design might attract the user on the first, but if the backend sucks; adios muchacos.

I have a feeling that he doesn't understand that to be a truly great designer, one has to have a great knowledge of the backend programming as well. Design borders dont end at the front. They strech deeply into all the lines of code. And for a product to work nad become great, designers must become engineers and vice versa so that they both get best of both worlds.

I suggest the author to look more into 37signals, and how theyre designers operate. There is an excelent video on peepcode where Brian Singer shows his design methods. Allthough you need to pay to see them (24$), they are one of the most valuable insights in the design process.

</comment><comment><USER10> Here's why many "rock star" designers don't like (generally) working for a single company or brand like a startup. First you have to understand not all designers are created equal. You tend to have "Rock Stars" (or in the agency speak a Creative Director) and a spectrum down to "production" designers. "Creative Directors" tend to be good at a lot of the different design disciplines, they understand business objectives, they can help with product and feature vision, they understand usability and they can make things pretty. Its the entire package.

If they go to work for a brand new startup they start with a blank slate, all the needs and challenges are large and the designer is fully engaged because they have to draw on all their different skill sets to solve problems.

But as time progresses the needs of a startup tends to shift from where there is less need to do full UX the product is now defined and its about making small incremental changes. This is where they go from being a "Creative Director" to a production designer. As a CD they get to design the web site with a brand new look and feel, as a production designer they're doing a new module on the home page which matches the existing design standards.

Basically the challenges keep getting smaller, and the designer is less engaged. There's a similar arc in development, however while at first you need to do "Big Things" (get the site up) and some of the changes become smaller, at least those small things can be as challenging (or more so) then the "Big Things" (optimize the load time).

Finally as a designer you live and die by your portfolio, and having a one site portfolio gets you nowhere. Unless you're looking for a big exit you're much better off getting more work, and more projects it both grows your portfolio and expands your experience and abilities.

<comment><USER11> Hi, I understand what you are saying. But I couldn't really agree on how designer becomes less engaged as startup matures. I think that's the one big misconception a developer (and designer) gets when they think of startups. Because in reality, the amount of work one can do in any given startup is unlimited. If there are no work then you create work, it's do what's best for the company. It's a life-long cycle.

</comment></comment><comment><USER12> "Why? This is the result of a designer under-valuing the importance of what his/her work can bring to the table in a startup. IMO, a rockstar designer should take more stake in a company than a rockstar developer. Look at Apple, I'm not so sure if their designer(s) took much credit for what they did in turning around that company (Unless Jobs designed the ipods/iphones/macbooks himself, which I doubt)."

With Jobs's recent passing, the last sentence is a statement that has plenty of evidence and testimony to argue either way. It doesn't bode well for your overall argument for you to say "Did Apple designers get enough credit? Who knows? Who can be sure?" and leave it at that.

</comment><comment><USER13> If you are going into the real estate business, you partner with building engineers, not interior decorators. Designers are interior decorators. Although they create an immense amount of value, once their work is done, they are not so much needed afterwards.

<comment><USER14> Unless its a company that generates content on a timely basis. In that case it's possible the reverse is true. Once the platform is up and running the programmer is not needed as much as the designer.

It's all about context.

Every company is different and the proper number of programmers to designers will depend on the needs of the company.

If a company reaches a point that it doesn't need as many of one side, then there's a chance it's close to not needing as many on the other. But if the company wishes to grow then chances are they will still need both.

</comment></comment><comment><USER15> I totally agree. I'm a designer/developer (better at design) and I have a company, I don't freelance. I make that distinction very clear. Sure, the company has me as its only employee but that's temporary. Now, the article's title seems a bit misleading. It sounds more like the author is advocating that designers stop freelancing and join a startup full time, not to stop freelancing and start a company.

I wish the post had touched on topics like the fact that considering or calling yourself a freelancer is short sighted and that starting a design company can be better for your bottom line in some markets.

That said, I also feel a bit bad for many of the people who will read this. At least the ones who are designers. These days there are about as many people who think they can call themselves designers as those who think they have the next big app idea. I include myself in this. Anyone nowadays can read some NetTuts, get a book on HTML and think they're a designer. It sucks and it hurts the good ones out there.

While I cringe lately at posts like this that give hope to people who have no business in the areas of design/development/entrepreneurship, I'm also glad they show up here on HN as I myself needed them about a year ago to get where I am today. I'm not an iota as skilled as a lot folks here on HN but I'm glad that the few who do have "it" (as in, "what it takes") get to read this and hopefully it fuels them to do things the rest of us only wish we could do.</comment>


MyGengo is now Gengo - <AUTHOR> http://mygengo.com

<comment><AUTHOR> My full blog post:

Today we have some great news.

It's been more than three years since we started our company—just a couple of friends in an apartment. There are now over 40 of us, in Japan, the USA, Germany, the UK and China.

We offer translation into 24 languages. Several million words are translated every month. We have over 5,000 truly tested translators in all timezones. 95 percent of jobs began in less than 28 minutes after the order was placed. And 99.996 percent of jobs are successfully approved by our customers, who number in the thousands.

We're proud to now provide both a simple translation tool for individuals, as well as a platform and API for others to build a multi-language web. Among our customers who go global by using our API are international apparel companies, car manufacturers, a vast number of E-commerce websites, CMS solutions, localization solutions, well-known tech blogs and many more.

In addition, we've seen a number of new companies built from the ground up on our API.

So now, back to the news. As you might know, the name myGengo was based on the Japanese word "Gengo" 言語 (with a hard "g") which means "language." We added "my" to make the language more personal.

But today we simply become "Gengo."

It's shorter, handier and easier to remember. It represents the simplicity and power that we want to offer to all our users.

Gengo reflects the global aspirations and perspective of our users. And if you like to think of a future where cross-language communication is simple (we do!), it's now a verb.

So Gengo your blog to Japanese. Gengo an email to Spanish. Just Gengo it!

Have fun,

Robert Laing & Matthew Romaine Founders, Gengo

P.S. Oh, and we also made some changes to our website. Hope you like them. Over the next few months you'll see even more improvements. Don't forget to check out what's going on right now on Facebook, where we are celebrating the name change :)

<comment><USER2> Downvote. Non-news. Why aren't you linking to your "full blog post". Why are you including the full blog post here? Why are you submitting your own articles? Why are you the only commenter on your own article? Why are you being so overtly promotional on HN?

<comment><AUTHOR> Sorry man. We all worked hard on this and were excited to get it out; it's been well-received by our users and I wanted to post it. Did not mean to offend.

</comment></comment></comment><comment><USER3> Looks like you need to update some of your client side JS to set the proper environment:

      /**
       *	Sets a variable, given our current domain. If we're running on a dev
       *	environment, it stays out of the hash and falls to dev.
       */
      mg_.env = {
      	'staging.mygengo.com': 'staging',
      	'qa.mygengo.com': 'qa',
      	'mygengo.com': 'production'
      }[window.location.host];
      if(typeof mg_.env === 'undefined') mg_.env = 'dev';

<comment><USER4> Thanks!

</comment></comment><comment><USER5> Congrats! Rage On!

</comment><comment><USER6> Spam.</comment>


Ask HN: Best Hacker News client for iOS? - <AUTHOR> I've encountered some grief finding a suitable Hacker News client for iOS (iPhone and iPad), which is bizarre because a cursory search on the App Store reveals so many of them.
My (if I may say so myself) fairly basic criteria are that the app I choose must function both on iPhone (preferably optimised for iPhone X) and iPad and allow me to log into my account to comment as myself.
This has turned out to be quite a chore. I've tried free, paid, in-app-purchase, and subscription-based (!) apps. They tend to suck quite diffusely: many do not support logging into one's account of those that purportedly do, many return an (inappropriate) authentication error (and are so >1 year old, so I suppose some change in the login API some time ago caused this state of affairs and that the apps have languished unmaintained since then). "Boreal" is particularly infuriating as it requires a subscription to log into one's account and to read more than 75 stories per week, and once paid for doeen't log in anyway.
I've settled on the free MiniHack as being the best one so far, and it comes extraordinarily close to meeting all my criteria (the only shortfall is lack of optimisation for iPhone X's screen, and lack of notifictions).
"Hacker Buzz" is the newest and looks graphically very promising, but doesn't support login. I haven't heard back from the developer I tried to contact through the feedback form either.
What apps do you recommend? (For various reasons, I'm not really a fan of using the web-browser, so please don't go down the "just use the webpage" route... of course one can use the webpage, but I'm looking for stand-alone app solutions.)
Thanks. <comment><USER2> I'm very curious to know what the various reasons are against the web browser. I've tried many clients over the years, and nothing has ever beaten the browser. HN is super fast to load, I get all of the functionality, the layout works well, it's dense enough to allow me to quickly skim but light/structured enough to not make it a chore, and I get all of the advantages of bookmarking, tabs, browser syncing, etc that Safari provides.

<comment><AUTHOR> It's a matter of mental gymnastics and "containers": accessing anything through the browser requires first switching to the browser, and then getting to a page (or tab, or whatever) inside the browser, which is two hops — it's a nested operation. Switching to a dedicated app is one hop, and is cognitively more proximate as it is a flat hierarchy with no nesting.

<comment><USER3> I hear ya. I think it might be nice to be able to create psuedo-apps that function as Safari/Chrome bookmarks.

<comment><AUTHOR> At one point I did just that: I put a "web-app" bookmark on my iOS home- screen. It worked, up to a point, but is very dissatisfying for a whole host of reasons (mainly, it messes with the browser's state).

<comment><USER3> Hmm.. it's too bad that doesn't work better, because at least for HN, I find the webapp to be pretty decent.

</comment></comment></comment></comment></comment><comment><USER4> MiniHack. Tried a bunch of free apps then paid for it after some googling. Supports login and comments. Has a dark interface theme.

<comment><AUTHOR> As I wrote in the post, MiniHack is the one I have currently settled on.

My only concern is that it appears only very lightly maintained, hasn't had an update for the iPhone X's screen, and has no support for notifications.

<comment><USER4> Your post says "free MiniHack" app. I don't see one in the App Store.

<comment><AUTHOR> Here it is: MiniHack - Hacker News Client by Cai GuangShao [https://itunes.apple.com/it/app/minihack-hacker-news- client/...](https://itunes.apple.com/it/app/minihack-hacker-news- client/id631108846?l=en&mt=8)

<comment><USER4> That's not free!

</comment></comment></comment></comment></comment><comment><USER5> Have you tried this one?

Hacker News (YC) by Dharmesh Patel [https://itunes.apple.com/us/app/hacker- news-yc/id713733435?m...](https://itunes.apple.com/us/app/hacker-news- yc/id713733435?mt=8)

It's worked fairly well for me as a light user.

<comment><USER6> I've also settled on this one as the least sucky.. There are still some issues as you can't easily see your comment history, and there's often a bug when you click a story directly, you can't see the content..

But again, its the least sucky I've found

<comment><AUTHOR> None that I have seen allow one to easily see and track one's comment history. That would seem to be a pretty desirable feature, but it is not implemented by anybody, which is bizarre.

</comment></comment></comment><comment><USER7> I've similarly tried about eight apps, on both iOS and Android, and have never found an app good enough to keep.

Instead, I use [https://hckrnews.com/](https://hckrnews.com/)

The main feature is to order front-page stories by time, rather than by score.

This lets you easily find the latest content, instead of needing to review all 20+ titles on the front page to see if anything is new.

The about page has a great feature list. It solves almost every pain point I have with HN's interface in a thoughtful way. Any further description would be a poorly worded rehash.

Check it out: [https://hckrnews.com/about.html](https://hckrnews.com/about.html)

</comment><comment><USER8> My setup is like this

RSS Reader (Web/iOS/Android): Import [http://opml.SharjeelSayed.com](http://opml.SharjeelSayed.com) , into Inoreader.com

News Notifications (iOS/Android): Add [http://rss.SharjeelSayed.com](http://rss.SharjeelSayed.com) into the 'Feed URL' field in [https://IFTTT.com/applets/456148p](https://IFTTT.com/applets/456148p)

[http://rss.SharjeelSayed.com](http://rss.SharjeelSayed.com) has the 'Must Read' part of the OPML file [http://opml.SharjeelSayed.com](http://opml.SharjeelSayed.com) so I get alerts for important stuff.

theoldreader.com works well too on the mobile browser (Safari/Chrome). Import [http://opml.SharjeelSayed.com](http://opml.SharjeelSayed.com) into it.

</comment><comment><USER9> Safari works well for me.

<comment><AUTHOR> " _I 'm not really a fan of using the web-browser, so please don't go the "just use the webpage" route..._" Why did I even bother writing that?

<comment><USER9> I'm an iOS developer. I once considered writing a Hacker News app. After looking into what would be involved, I decided it would be a waste of time. The API is inadequate and YC makes no guarantees about future expansion.

<comment><AUTHOR> Fair enough… but still, there's clearly a big population, and tracking changes in login systems is nothing new, is it?

</comment></comment></comment></comment><comment><USER10> Not a HN app, but works fine: Reeder + feedbin.me

Keeps you logged in if you want to comment/upvote. Tracks all stories that managed to main page via RSS feed.

</comment><comment><USER11> I can give a strong recommendation to Materialistic - [https://play.google.com/store/apps/details?id=io.github.hidr...](https://play.google.com/store/apps/details?id=io.github.hidroh.materialistic&hl=en)

It has every feature you asked for and its a pleasure to use. The only place it fell short was the lack of a downvote feature.

<comment><AUTHOR> Uhm… am I missing something blindingly obvious or is this an app for Android, not iOS?

<comment><USER11> I'm so sorry. I got mixed up. The client I use on iOS (Hacker News Zero) is good doesn't have the features you wanted, like login.

<comment><AUTHOR> I'll keep it in mind just in case I ever switch to Android. ;)

</comment></comment></comment></comment><comment><USER12> If you just want to browse/read, I recommend "Hacker News Client" [https://itunes.apple.com/us/app/hacker-news- client/id9394542...](https://itunes.apple.com/us/app/hacker-news- client/id939454231?mt=8)

</comment><comment><USER13> I use reeder and am very happy with it.

</comment><comment><USER14> I don't think it's a good idea for any app developer to make an app that lets you login to a website that they don't own, especially that doesn't offer an authentication API. What happens when the website changes anything? The app breaks immediately...

The best Hacker News client for getting the headlines is [http://hckrnews.com/](http://hckrnews.com/)

You didn't list any criteria besides "runs on iOS and lets me login". A webbrowser is a native app which fits that criteria perfectly - so what's your reasoning for not wanting to use it and what do you want an app to do that the webbrowser app can't do?

<comment><AUTHOR> I don't want to go through a browser. That's a fundamental desire.

<comment><USER14> That's fine. I can relate to having a strong preference for something that other people don't really get. But, I can usually explain why. (Usually!)

I'm just curious - what's the reason that it's a fundamental desire?

<comment><AUTHOR> As I have explained elsewhere in the responses, it is a matter of "mental gymnastics": using something through a web-browser entails two nested operations: first switching to the browser and then browsing to the content (via URL, bookmark, or tab choice) whereas switching from one app to another is a flat hierarchy.

<comment><USER14> If you put a link to the website on your home screen, it opens in a separate app from the browser.

</comment></comment></comment></comment></comment><comment><USER15> Reeder

<comment><AUTHOR> Can you post comments as yourself through Reeder?

</comment></comment><comment><USER16> I use Feedly not only for hn

<comment><USER17> I also use feedly, but you can't comment there, right? And you do not see the source of the link, which is sometimes quite helpful</comment></comment>


Run MacBook Retina at Native Resolution - <AUTHOR> http://osxdaily.com/2012/06/18/3-ways-to-run-a-retina-macbook-pro-at-2880x1800-native-resolution/

<comment><USER2> I have an rMBP. I had been running it at the largest supported resolution (1920x1200). I just downloaded SwitchResX and set it to 2880x1800.

It seems to work perfectly. Everything is smaller, but perfectly proportioned, and there don't appear to be any weird issues like with windows via bootcamp (which has some things small and others big).

My eyes are good, and this screen real-estate looks amazing so I'm going to give this a go for a few days.

<comment><USER2> After a few hours I've switched back to 1920x1200. I still love the huge native resolution, and will switch to it in certain circumstances, but for regular web-browsing, email, text writing, etc, it is more comfortable at 1920x1200.

When I'm developing in Xcode or for the web I will switch back to 2880x1800 to get maximum real-estate for many windows.

<comment><AUTHOR> Thanks so much for the reply. Think I'll be getting one soon!

</comment></comment></comment><comment><AUTHOR> I'm considering buying a Retina MacBook. Can anyone that has one confirm that this works, and comment on what it's like?</comment>


Programmers are not different, they need simple UIs - <AUTHOR> http://antirez.com/news/107 <comment><USER4> One problem is that people are too macho to admit they have cognitive limits.

I know people in the finance business who are sending their CTO's out to take the Series 7 exam because to write code for some domain you need to understand something about the domain. That is on top computer science principles, your programming language, the "standard library" for your programming language, libraries you use on top of that, your build system, your version control system, and all kinds of stuff.

And now people think they are going to be left behind if they don't learn Angular, Rust, Shiny7 and all of that.

Every bit of bullshit steals your cognitive capacity and turns you into an 0.1x programmer.

<comment><USER5> As an artist as well as a programmer, I've learned a lot about the techniques of professional artists. Most are specialists, not generalists. They have a specific, focused toolbox, and they _do not leave it_. If a guitarist gets _that_ sound from _this_ guitar and amp and pedals and scales and rhythms, he sticks to that. If a painter prefers these subjects and those brushes and paints and canvas sizes, she sticks to that.

Become proficient in a medium to the point where absolutely no conscious thought is required to use it to its fullest extent. That's the secret of great artists.

Apply that to programming, now. You can learn a field and the core tech of the field, and get a lot done for a long time. Or you can go chasing the new and shiny every six months and drive yourself up a wall and spend all your time _learning_ instead of _making_.

<comment><USER6> What if you make your core competence as a programmer "gaining steady footing in new tech", along with basic like code structuring, version control and some automation (CI/testing etc.)?

That way you might not become "the greatest X86 assembly programmer" or whatever niche you like, but you might become a very proficient system integrator, which is useful in its own right.

<comment><USER5> Oh, that's me. I'm a mile wide and an inch deep. So I can do a lot of things, most of them not very well. My niche friends are _much_ better than I am at anything I can do, but I can do a lot more things.

It's worked out kind of weird, pushing me (after a long career) into being a founder, and building a tool for generalizing common problems in systems integration. :) My desire to wear lots of hats finally works! But really? I'm more or less a specialist at being a generalist. And I've _learned_ not to chase shiny new tools, because they're very distracting.

<comment><USER7> I'm the same way! I try to get good at something, and then immediately move on. I am the best at nothing, and better than almost no one. But I am the only person I know that can write code, swordfight, surf, use a ham radio, play a handful of instruments, build things out of electronics, draw and paint, shoot, blacksmith, and blow glass (all at the same time -- just kidding)! I make myself very happy by being able to try something and then practicing until I get "good" in my own opinion. It's absolutely true that up against pros I am pretty terrible! I have also come to understand over the years that this is a byproduct of having a hacker mentality. I am loathe to use that word in reference to anything I am or anything I do, but that's just what I see. Hackers are curious creatures, and so it follows that they can do a lot of things.

<comment><USER8> It's often really hard to judge how skilled you are at something. [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) is overblown, but being able to say do a crappy weld in 4 hours that a competent person can do better in 15 minutes is often just dangerous. Many a handyman has caused 20,000+$ worth of damages or gotten someone injured.

That said, hobbies don't need to be productive and half assing something is often good enough. Yes, a simple wedge doorstop may damage the door, but well sometimes that's just not an issue.

<comment><USER7> Did you mean to reply to my post?

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> _... I want to stress how important is the concept of simplicity, not just in graphical UIs, but also in UIs designed for programmers._

I've always felt sad that this dichotomy is so strong in our industry. There are graphical tools for proles and then there are text-based tools for programmers, and never the two shall mix.

It didn't have to be this way. Smalltalk was an integrated graphical system for both programmers and users already 40 years ago. Something like the Smalltalk class browser with visual editing of live code would feel revolutionary even today compared to most of the systems we have.

But we're seemingly stuck with another '70s approach, that of Unix: streams of plain text, UIs based on undiscoverable and inconsistent command line argument arrays, all glued together with a spider's web of incredibly fragile string- replacement tools like shell scripts and templates.

<comment><USER10> Agreed. Mostly a result of "if I had to learn it so should you" and stuck-in- the-mud attitudes.

Look at the Linux systemd / init debate. Despite the fact that sysvinit is clearly ancient, awful technology there are still people who have spend time learning it and don't want something better.

Another example: bash. Clearly an awful awful language/shell but it sticks around because too many people can't admit that _the thing they know is rubbish_.

<comment><USER11> > Another example: bash. Clearly an awful awful language/shell but it sticks > around because too many people can't admit that the thing they know is > rubbish.

You should try thinking about what a better bash would look like, it's not as simple as you make it to be. I think the best I've seen in this direction is rc and I think that's still not enough to compensate for the loss of ubiquity.

The stuff people come up when they try to "redesign the unix terminal" (usually some javascript contraption) is always extremely lacking.

<comment><USER10> It's not simple, but it's not hard to imagine. Some of these things exist already:

* Image support (I can't remember where I saw this but it exists)

* Structured data piping (in Powershell)

* Machine-readable command-line arguments, which would enable...

* ...Proper autocomplete (like in IDEs)

* Real types (Bash is 'stringly typed')

* Sanity (e.g. look at how `[` is implemented in Bash; none of that)

* A better way to integrate with programs than running them on the command line (e.g. shell bindings).

That last one would be tricky and really requires moving away from the C ABI as the Lingua Franca of libraries. That is probably quite far away in the future unfortunately.

<comment><USER12> Regarding (1), a proposal that had some impact was TermKit[1], which was supposed to auto-detect the type of data coming from stdout and display it intelligently. It died on the vine, though[2].

[1] [http://acko.net/blog/on-termkit/](http://acko.net/blog/on-termkit/)

[2] [https://www.reddit.com/r/programming/comments/137kd9/18_mont...](https://www.reddit.com/r/programming/comments/137kd9/18_months_ago_termkit_a_nextgeneration_terminal/)

</comment></comment></comment></comment></comment><comment><USER13> I honestly believe this is the reason why React is currently winning the web tech wars. The API is minimal, clear and concise. Once you've mastered the few functions and concepts, you rarely have to reference the documentation and understand what tools you have to solve a problem. A major source of frustration with me as a programmer is implementing something only to find the library or framework I'm using has already included it in its core, it's just not in the documentation or hidden in a huge API reference. It's a refreshing experience when libraries and frameworks appreciate the product and the programmer.

<comment><USER14> I can't necessarily agree with this, as while React itself is very simple, you will find that after sufficient experience with it in the real world, you need its ecosystem and surrounding libraries, and this can be absolutely daunting for some.

e.g. NPM, Webpack, Flux/Redux, React-Router, Thunk, DevTools, CSS, etc.

<comment><USER15> But compared to something like angular react is minimalist.

<comment><USER16> But compared to something like GWT, angular is minimalist :) Surely that doesn't mean we should all settle with angular, does it?

</comment></comment></comment></comment><comment><USER17> This sentiment—that application programming interfaces are user interfaces, and that programmers are users—is why I'm spending so much effort improving the API of D3 4.0. I wrote about that in March: [https://medium.com/@mbostock/what-makes-software- good-943557...](https://medium.com/@mbostock/what-makes-software- good-943557f8a488)

<comment><USER18> Please consider making it easier to _debug_ as well. JavaScript has some excellent debuggers available to it-- D3 (at least the older version I used) seemed almost designed to defeat every useful feature of those debuggers.

<comment><USER17> It's interesting—or frustrating?—that you should mention this, because D3 _is_ explicitly designed with debugging (and debuggers, developer tools) in mind. I'd like to understand your frustrations better.

There are two main strategies that D3 uses to facilitate debugging.

First, whenever possible, D3's operations apply immediately; for example, selection.attr immediately evaluates and sets the new attribute values of the selected elements. This minimizes the amount of internal control flow, making the debug stack smaller, and ensures that any user code (the function you pass to selection.attr that defines the new attribute values) is evaluated synchronously.

This immediate and synchronous evaluation of user code is in contrast to other systems and frameworks, including D3's predecessor Protovis, that retain references to your code and evaluate them at arbitrary points in the future with deep internal control flow. I talk about this a bit in the D3 paper (and the essay I linked above): [http://vis.stanford.edu/papers/d3](http://vis.stanford.edu/papers/d3) Even in the case of transitions, which are necessarily asynchronous, D3 evaluates the target values of the transition synchronously, and only constructs the interpolator asynchronously.

Second, and more obviously, D3 uses the DOM and web standards. It doesn't introduce a novel graphical representation. This means you can use your browsers developer tools to inspect the result of your operations. Combined with the above, it means you can run commands to modify the DOM in the console, and then immediately inspect the result. D3's standards-based approach has also enabled some interesting tools to be built, like the D3 deconstructor: [https://ucbvislab.github.io/d3-deconstructor/](https://ucbvislab.github.io/d3-deconstructor/)

<comment><USER18> It's been awhile since I had to use it, but I recall the most common frustration from me was getting an unhandled exception with a call stack like:

AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod -> AnonymousMethod

Occurring hours after I'd actually created the code that caused the exception.

Since I've moved jobs since then, I can't give a more specific example, sorry.

> that retain references to your code and evaluate them at arbitrary points in > the future with deep internal control flow.

For the record, that appears to be exactly what was happening to me when I was struggling with D3.

<comment><USER17> Without a more specific example to go on, it's difficult to speculate. The only case where you'd get an error asynchronously should be in the case of transition.tween or an event listener—cases where the code is necessarily asynchronous—and not something like selection.attr or transition.attr, where the code can be evaluated synchronously.

It's true that D3 uses closures and anonymous functions internally. But assuming you are using a debugger and the non-minified code, you can use that debugger to see exactly what the code is doing. To continue with the example of selection.attr, the implementation is here:

[https://github.com/d3/d3-selection/blob/master/src/selection...](https://github.com/d3/d3-selection/blob/master/src/selection/attr.js)

So a typical call stack would be three deep: selection.attr > selection.each > attrFunction's closure.

</comment></comment></comment></comment></comment><comment><USER19> I completely agree with the sentiment. And this is why such a statement made by antirez leaves me puzzled.

I admire Redis for its performance and simplicity of setup, but if there is one thing that Redis does not have is a coherent API.

Whenever I use Redis, I absolutely need the command cheatsheet, as it seems that every command works differently. There is no commonality in data structures. The whole thing seems more dictated by the underlying implementation than the desire of providing a simple API.

For instance, why LPUSH accepts multiple parameters but LPUSHX does not? Why there is even hyperloglog in a database? Where did the need for RPUSHLPOP come from? Why the options for SCRIPT DEBUG are YES, SYNC and NO?

I don't want to be too negative. I appreciate the great work that has been done on Redis, but I feel it really needs to rethink the whole API layer.

<comment><USER20> Most of redis' API is quite coherent. Some of the incoherence is due to the fact that some commands get less attention, such as LPUSHX (which I've never really noticed and I've been using redis for 6 years). Some is because of the core idea of remaining backwards compatible, so even if you have option or commands added, they will never replace old ones, which can cause a bit of complexity and inconsistency.

> Why there is even hyperloglog in a database?

Remember that redis is not really a database but a "data structure server". I have to say I personally don't think this should have been part of the redis core, and it's a textbook example of what redis modules should be, but it came 2-3 years before modules.

> Where did the need for RPUSHLPOP come from?

It came from distributed work queues, which are a popular use case for redis. The documentation actually goes into great detail explaining how to use it.

<comment><USER21> LPUSHX got my attention so I opened a pull request making it variadic (along with other commands) three years ago [1]. Of course since then the codebase changed and it can no longer be merged.

If there is still interest I could try to fix it, although I don't use Redis as much anymore and I have not looked at its code for a long time.

[1] [https://github.com/antirez/redis/pull/1232](https://github.com/antirez/redis/pull/1232)

<comment><USER22> Hey! Yes I'm interested, the PR was not handled for the usual reasons but making the commands variadic is a good idea. However I'm surprised there is not just the need to change the command table since I remembered, incorrectly, all the variants were handled by a single function.

<comment><USER21> Yeah, as you can see the issue was that it is a different function, pushxGenericCommand(), which is used for LPUSHX, RPUSHX and LINSERT. For me having the same function for LPUSHX / RPUSHX and LINSERT does not make much sense (it uses different code depending on whether or not an argument is NULL anyway) so I had started by making LINSERT not rely on it.

My initial goal at the time was not to make LPUSHX and RPUSHX variadic, since like you said they are not used so much. It was actually to make LINSERT variadic, which can result in a significant performance boost compared to calling it several times.

Anyway, I will try to find the time to adapt it to the current code base.

</comment></comment></comment></comment></comment><comment><USER23> I love the rise in appreciation for a solid user experience for programmers these days. I've heard this referred to as DX (Developer Experience).

I have such a feeling of empowerment and productivity when I'm working with well-designed tools and APIs, with interfaces that fit into my mind the way the handle of a hammer fits perfectly into my hand.

<comment><USER24> I would say the concept of DX is rising not just in terms of UI, but in the holistic sense. For example, Windows releasing the Ubuntu Bash and Microsoft Code in an attempt to make Windows a better DX environment.

<comment><USER25> Windows had an excellent DX before WSL; Visual Studio in particular is considered a best-of-breed development tool and ecosystem, years ahead of anything that's available under Linux. Linux only won in the Web space because it's easier to deploy at massive scale because no licensing costs. It is _not_ the easiest OS to develop for.

<comment><USER26> JetBrains IDE seems much more productive than Visual studio while at the same time being lightweight. So much so, lot of people find it worthwhile paying 300usd per year for Resharper, to get the same tools on Visual studio.

</comment></comment></comment></comment><comment><USER27> Good API design is part of why I try to follow TDD.

I'm not dogmatic about it, but I've noticed that when I do follow it, I usually have a better understanding of how I'll use my code by the time I'm done implementing it. Usually because, in the process of testing my code, I'm getting to 'use' it before I've even written it.

<comment><USER28> This resonates with me. But, I have found that it is often more important to do several to "throw away" than it is to TDD the first.

That is, I have yet to find a process TDD/BDD/Whatever, that can truly up the viability of iteration 1 of a program. Instead, it is by iteration 3 that things have a chance. And, it seems, any process is likely to succeed then.

<comment><USER29> BDD allows you to "think through" the consequences of your user stories and potentially discard or amend bad stories before they end up getting implemented and causing problems.

<comment><USER28> Again, this resonates well. However, I have had many cases where I did not really see what made a story bad until I had almost succeeded in getting it implemented.

In the end, I always want a way to make iteration 1 work. For it to be the only time I have to write something. However, experience is having done many many first iterations.

</comment></comment></comment></comment><comment><USER30> The goal is to maximize developers' investment. Sometimes simplicity is needed but there are other ways.

For example, _consistency_ : it takes long enough to figure out a new module without also having to re-learn all of the things you did arbitrarily differently from the previous module. Pay attention to naming, argument order, styles of error-handling, etc. and don't abbreviate things that are not extremely common abbreviations (e.g. "HTML" is OK; getHypTxMrkpLang() is a PITA).

Also, if you include lots of examples that obviously work then developers are more likely to trust what they see. Python "doctest" is brilliant for this, since you can trivially execute whatever the documentation claims. Don't document the ideal world in your API: document what it _actually_ does.

Make your API enforce its own claims in code. Don't assume that a developer will have read paragraph 3 where it "clearly says" not to do X; instead, assert that X is not being done. This is extremely valuable to developers because then they _can't_ do what you don't expect them to do and they won't start relying on undefined or untested behavior.

</comment><comment><USER31> I would argue that simplicity and elegance are even more important for mental models than they are for physical objects.

<comment><USER32> To take that one step further, I would even say that a physical object is merely a touchable proxy for a mental model. Think of how many things you just "know" how to use because of elegant or established design patterns. Or how you move about your own kitchen when preparing a meal.

<comment><USER33> > I would even say that a physical object is merely a touchable proxy for a > mental model.

This resembles Plato's Theory of Forms: [https://en.wikipedia.org/wiki/Theory_of_Forms](https://en.wikipedia.org/wiki/Theory_of_Forms)

> These Forms are the essences of various objects: they are that without which > a thing would not be the kind of thing it is. For example, there are > countless tables in the world but the Form of tableness is at the core; it > is the essence of all of them.

</comment></comment></comment><comment><USER34> >> The act of iterating again and again to find a simple UI solution is not a form of perfectionism, it's not futile narcissism. It is more an exploration in the design space, that sometimes is huge, made of small variations that make a big difference, and made of big variations that completely change the point of view. There are no rules to follow but your sensibility. Yes there are good practices, but they are not a good compass when the sea to navigate is the one of the design _space_.

Love this paragraph. That's why it's art.

</comment><comment><USER35> This isn't wrong, but the problem in general is that non-programmers have pre- decided that "simple UI" means a clickable GUI, probably with a Paperclip type assistant.

The benefit of the GUI is to present something that text can't - such as lines between components, or pictures, etc. But what's the (specific) domain use for those thing? If there isn't one then a GUI is just a text UI with a mouse pointer and a bunch of overhead.

There's almost zero connection between what seems simple to your boss in a screenshot and a productive tool. If someone really removed unneeded complexity from a burdened UI, then great, but one person's bell and whistle is another's required tool.

<comment><USER36> Agreed. I've seen many simple, bulletproof UIs and APIs that only support a discrete set of workflows, so they ultimately fail as expert tools.

Sometimes you don't want an expert tool, you want an easy button. That's fine. But often there's an inherent tension between 'can never fail' and 'lets you open up the throttle and tear through your problem'.

Compare the editing and reviewing workflows supported by a share drive and those supported by git. A shared folder is undoubtedly simpler, but good luck maintaining a coherent revision history or editing a document in parallel on different isolated subnets.

</comment></comment><comment><USER37> The central thesis here is that APIs should be treated like GUIs. Make them as intuitive as possible to minimize brain space waste (ie. memorization of non- transferable, vendor-specific knowledge)

Sadly, the post is too short to discuss what "intuitive" means for an API (which could probably fill several volumes).

<comment><USER38> I've built GUIs that completely contravened every possible thing I've ever seen written about GUIs. For example, _one ugly button_. No "exit" button even - you can hit the X in the corner for that.

Behind that button, there was no possible way to make a mistake. Now, to be fair when a constraint was violated ( which only happened when something physically broke or somebody didn't set a physical thing up right ) there was a comprehensive explanation of the failure - "The U42 wire for the Gerfish Space Defarbrulator is disconnected or broken. Please refer to section 1.145.2 of the service manual." That happened in a popup.

To me, that's a good GUI - "just tell me when to go to it." But there is an ostensible public choice theory problem with this approach - who will be paid for training in it? Where will a support network for it exist? Nobody, and nowhere. Show this to people, and you can see it on their face - "there goes my job." They think this even after I show 'em the popup.

It's _asocial_ and that's more important that "it's correct." But it worked to sabotage any expectations people might have about me writing GUIs.

Also, when people tell me that corporations are cost driven these days, I just laugh because of this.

</comment></comment><comment><USER39> When people say we need to teach everyone how to code, I agree. But first we need tools that allow (any) people to code with different levels of knowledge and experience.

Like math: you learn basic Math. Then you have a calculator for basic operations. Then you have MS Excel for general professional use. Then you have MatLab/R and stuff for specific use.

For programming I have the impression that you learn to code and then you, from start, have to learn how to use the most sophisticaded tools in place. And several of them.

<comment><USER18> > For programming I have the impression that you learn to code and then you, > from start, have to learn how to use the most sophisticaded tools in place. > And several of them.

Right; and if someone makes a tool which is (attempts to be) more friendly to use, it's constantly derided by "real" programmers. Look at, for example, Access, Visual Basic, PHP to some extent.

The correct answer to, "people are using Access to write software" shouldn't be:

"that is garbage! They need a real DBMS! With multi-user support!"

It should be:

"well, Access is clearly showing us that there's a huge under served market of people here, let's figure out what it's doing that appeals to them then work on an improved version."

<comment><USER40> While I agree, it bears mentioning that sometimes the thing that appeals is popularity itself, or good marketing, or "written by Microsoft". It would be a wonderful world if people always chose solutions on technical merits, and the best solution always won, but I don't think we live in that world.

<comment><USER41> or "It's what I have on my office computer and I don't get admin rights"

</comment></comment></comment></comment><comment><USER42> Sorry, couldn't bring it up to read the article. It was rendered on my screen in what looks like a "programmer" font on a page that looks to be made for "programmers". It is basically plain white with a wall of black text in a font that strains my eyes. Or at least at my phone.

Programmers are not different, they need equally readable websites.

P.s. ;) or ;(

P.s.2. In before the "HN is also xyz". HN might not have fancy styling but it did carefully consider readability.

<comment><USER43> This is the first thing I noticed also. Maybe the use of a fixed-width was meant to be ironic since the author is comparing against UX design?

<comment><USER42> I'm afraid not :(. Also, fixed-width is not the only issue. The chosen font type and spacings look real programmy but are not pleasant to read.

</comment></comment></comment><comment><USER44> In my opinion, a poor developer experience is the primary reason GWT never got more traction than it did.

It's quite the technical accomplishment, but it's challenging to use in ways that have no reason to be challenging from an experience perspective.

</comment><comment><USER45> It's frustrating for me that people seem to be trying to force everyone into the same UI patterns, regardless of the target audience's skill level and difficulty of problem. Novice users need different UI's than do advanced users, ditto people solving easy problems vs hard problems.

Michael Schumacher and your 15yr old new driver need very different UI's. The new driver needs a simple UI and lots of protection from making mistakes to solve the easier problem of getting from A to B without crashing. Mr Schumacher on the other hand needs a complicated UI and 0 hesitation in the implementation of his decisions to solve the much harder problem of breaking the world record at Monaco.

Determine who your audience is, and how hard the task they're attempting is, then implement the appropriate UI. Defenestrate anyone who tells you simple or complex, GUI or CLI is "inherently better" without considering the problem.

Is red-eye reduction in MS Paint or Python PIL better than in Photoshop? Conversely, would you rather use visual studio or notepad to write a 2-line script?

<comment><USER46> > Michael Schumacher and your 15yr old new driver need very different UI's

The UI isn't different because the users are different. The cars are. An F1 car is crammed for a reason. This is a deeper problem than adjusting for users. And this is what most still don't get.

This UI vs functionality dichotomy does not exist. Any compromise is artificial. UI must be purely functional, and from function emerges pure form. A good designer is focused just as much on function, as is a good developer on design. In other words, they are the same person. And this is basically Apple's design philosophy in a nutshell.

A UI designer didn't design the cockpit of the F1 car, nor the Camry. They may have chosen the font, the shapes, the icons... but everything was already there. Function necessitates it. And the interfaces of both cars are incredibly simple.

<comment><USER45> Most still don't get it because it's not true. Look at all of the additional options with non-obvious discovery that Apple has added to the iPhone because some more advanced users want e.g. swipe up quick settings. If you as a user want more control, the design needs to include more controls. Open up MS Paint on one monitor and Photoshop on the other to see what I'm talking about. I realize that this concept is offensive to designers, but designer happiness isn't the goal. Good UI is the goal.

The UI's are different because Schumacher wants more precise control (brake- bias, suspension rate, turbo angle of attack, etc) and you can't get that level of control without a more complicated UI (you need the appropriate buttons and levers for all of those things).

The title of the person who lays out the Ferrari F1 car's cockpit is literally UI designer. If you think an F1 car's cockpit is simple then you should reconsider. The cognitive load of those two sets of controls is very different, made possible and desirable because one set of users is expert and the other isn't.

<comment><USER46> No. The UI designer does not choose functionality on their own. They need intimate knowledge of how the car and driver work together, and then must simplify to the bare necessities. The better they are at the job, the better they know about both. And same applies to the developer and even the driver. The best drivers are deeply involved with every aspect of their cars. And in the end, nothing is redundant.

And no, MS Paint and Photoshop are not the same program with one just having more options. Photoshop is a beast, and it's UI has improved over the years -- to match that functionality.

The UI is different because Schumacher is driving an F1 car.

> additional options with non-obvious discovery

This is bad design. iTunes and Apple Music are horrible also. Not everyone at Apple gets it. But everything that made Apple successful was about getting it. Steve Jobs got it.

> designer happiness

There is only designer happiness among those who don't get it. There is no designer-developer distinction to the user. Ultimately all there is is user happiness.

</comment></comment></comment></comment><comment><USER47> I feel one of the worst API tooling right now are the ones that come with AWS. Everything from the AWS Console's UX and accessibility to Dynamo's APIs are just a nightmare to understand and deal with day to day.

<comment><USER48> I don't understand why AWS' free-tier requires putting things into a VPC.

It is a complete turn-off. It took me _days_ to figure how to configure it correctly to access it through SSH without following a guide that builds out some giant infrastructure.

It should just be one-click to throw everything up that I need and hide all of that extra config behind a wall that I can access if I want / need to.

</comment></comment><comment><USER49> Much of the trouble with IDEs revolves around not coding, but finding all the parts. The usual IDE Does Not Play Well with Others. Most IDEs have some strong ideas built in about where Things are Supposed to Be. This causes trouble when they have to interoperate with some other system which also has strong ideas about where Things are Supposed to Be. (Makefiles, Cargo, Github, Go's tools, packaging tools, etc.)

Working around this involves either manually editing text files or trying to find the right dialog box into which to put some pathname.

The other big problem with IDEs is that they usually have no understanding of the tools they invoke. This is a UNIXism - programs take in parameters, but just return an error code. There's usually no machine-processable output from compilers or linkers. If you're lucky, the IDE might be able to associate an error message with the right source line in the right file.

</comment><comment><USER50> There is tension between the benefit of designing user-friendly APIs and the temptation to overspend on effort to design great APIs. It is sometimes hard to anticipate how often an API will be used.

<comment><USER51> > There is tension between the benefit of designing user-friendly APIs and the > temptation to overspend on effort to design great APIs. It is sometimes hard > to anticipate how often an API will be used.

I think in antirez's case there is little 'underestimation' :)

Returning to the more general practice - I agree, it's easy to spend several days building a nice abstraction for something that is not extended again, or something that is extended in a way different from what was anticipated and the abstraction doesn't help. From my experience what has worked the best in terms of internal structure, is to write a basic and working version (this is when you don't know that there are any other users) and to refactor it into a nice abstraction when you reach the point that it needs to be extended - <USER2> a huge positive is once it needs to be extended, you know what the abstraction is going to be used _for_.

<comment><USER52> I think that's really smart. That's what I do too. When you do the YAGNI way and start seeing it over and over refactor it to an abstraction. Challenging in the agile world though. Businesses don't want to pay for refactoring.

</comment></comment></comment><comment><USER53> >Learning to configure Sendmail via M4 macros, or struggling with an Apache virtual host setup is not real knowledge. If such a system one day is no longer in use, what remains in your hands, or better, in your neurons? Nothing. This is ad-hoc knowledge. It is like junk food: empty calories without micronutrients.

I agree with this. Too much time is spent in learning how to work with poorly designed interfaces. This sort of knowledge of man made, arbitrarily designed tools doesn't really teach us anything that applies outside the highly specific use case. And it will likely be obsolete within a couple few years. The half life of IT knowledge is short.

While complex tools might be unavoidable, we need better ways to interface with them. And better documentation. People rely on SO and the like to understand how to interface with an API, decode cryptic error messages or configure some tool because the documentation and interfaces are often lacking.

</comment><comment><USER54> UI's a funny term for APIs. I don't think it's that complex.

APIs are written documents describing external controls to a system's behavior. A good document can describe both the controls and behavior clearly and succinctly. A bad one can describe the same in long and convoluted language that effectively hides the underlying system. Often in a mess of "should" and "can" clauses, with lots of passive voice, vague assumptions, and unnecessary complexity and verbiage.

For some reason, I feel many programmers write documentation the same way that they wrote their X-page essays for English class. They're just trained to write fluffed-up junk that fills some imaginary requirements of a long- irrelevant class.

EDIT: To clarify: I'm describing the actual types and methods themselves. They infer an underlying mechanism and a means to control it.

<comment><USER55> An API isn't the document - it's the interface. (That's what the "I" stands for!) One which developers use, which would make it a type of UI even though it's not necessarily the UI that's exposed to end users. And that's kind of the point: the documentation should certainly be clear and well written, but the necessity of all that can be minimized by carefully designing the way developers can work with your tool in the first place.

<comment><USER54> Every identifier in the system is a bit of documentation. I submit that there's a difference when you name a function:

bool ufklsjblsboabfds(int, int)

and

bool operator<(int, int)

I know that to many, the idea of individual identifiers being documentation is a bit radical, but I think it's the first documentation a developer sees. It's the documentation built into the body of every piece of code that they read and write.

<comment><USER55> > I know that to many, the idea of individual identifiers being documentation > is a bit radical

I think the opposite – it's totally mundane to most people. Aside from the intellectual exercise it requires, people don't have any reason to use a language that used bool ufklsjblsboabfds(int, int) any more than they would use Brainfuck.

So, sure, the API "documents" the functionality in the most minimal way possible. But when you say "documentation" you're using a term that almost no one will understand in the way you mean it.

</comment></comment></comment></comment><comment><USER56> It's surprising that so many good tools are regretted because of lack of clear documentation and intuitive API (looking at you, Webpack).

No, a good user experience is not a luxury you can afford to omit. Stop creating backlog tickets to "simplify code". It's just plain selfishness.

</comment><comment><USER57> Nowhere other than in programmers' tools would it be considered an acceptable UI architecture to layer a GUI (usually a turgid dialog box) over a CLI. Moreover the dialog gives no indication whether the inputs are correct or consistent with one another until an unhelpful error is displayed. The components of a toolchain need real APIs and real libraries implementing those APIs, designed for the kind of object-action manipulation that makes desktop productivity software productive: You can't apply the wrong action to the wrong object. The UI simply won't let you.

</comment><comment><USER58> Never allow a user to do the wrong thing on your GUI - they must be guided toward the "pit of success."

The same thing can be said for an API. I've be pair architecting/coding a pretty substantial spike over the past two weeks with some hairy revision control and dependency management stories. The main thing we've been aiming for is making extremely sure that developers don't drop a dependency into our DAG. The solution was obvious, but the API design has _outright_ dominated those two weeks.

</comment><comment><USER59> Lets take Firefox as an example. Over the years they have been simplifying the interface, especially once Chrome came into the picture. Every time they remove something I find myself annoyed that a function I used, which was in an intuitive location, is now hidden away in a deep sub-dialog. That is, if it even survived at all.

I'll keep my complex UI thank you very much. Complex doesn't have to mean complicated.

<comment><USER30> Removing something is almost forgivable if it survives as a low-level configuration option.

Yet Firefox has changed behaviors that I _can't_ fix anymore, such as always remembering everything in a Downloads list (they outright removed any way to prevent this so one has to manually clear it).

</comment></comment><comment><USER60> I want simplicity and _longevity_.

A simple interface that is changing or obsolete is still useless knowledge I have learned.

Longevity is another reason a developer(s) should spend extra time getting their design polished. Get it right so the product can grow and does not need to introduce many breaking changes.

Make upgrades a joy, not a PITA.

</comment><comment><USER61> An example I currently have, Statistics Norway recently released version 2 of their API. You can now download about every data source they have. However they prefer that developers use JSON-Stat([https://json- stat.org/](https://json-stat.org/)) instead of CVS's. Luckily they do support CSV, but it is messy with inconsistent layout. I still prefer it over JSON- Stat though, as I feel JSON-Stat is way too complicated for serious use. That is also probably why there are so few JSON-Stat clients.

CSV's are simple to parse! JSON, XML are more complex beasts to parse, they are especially hard to parse when they don't fit in memory. I do use a lot JSON, dont get me wrong, but it's mostly for small data sizes.

Do anyone else here feel the same about JSON-Stat?

<comment><USER62> Anyone who claims that CSVs are easy to parse have obviously never had to deal with the kind of junk that you see in real CSV files. Quite apart from quotes (is a "a,b" two fields with '"a' and 'b"' or a single field with three characters?) there are also things like new lines like

like,"this newline"

Which are part of the field and not two records. Or having to deal with user names like Blue, Al (outlook's preferred format for representing people's names).

Or you end up with O'Reilly - is the ' part of a quoted string or not?

And of course a comma isn't necessarily the only separator - what about tabs? Or a document where an intermediary has saved it in an editor that has "helpfully" converted tabs to N spaces (where N is a universally disagreed upon nonzero positive integer)

<comment><USER61> You're absolutely right, but this is still a problem with JSON and XML. I have seen dates being represented in all kind of formats in the same document. Data cleansing has always been important when working with data in any format.

<comment><USER63> The difference is that JSON and XML can be described by a grammar and parsed by any standards-conforming parser. Good luck doing that with CSV.

</comment></comment></comment></comment><comment><USER64> Good interfaces are hard. Bad interfaces add chafe, cognitive load, friction, frustration, are hard to document, etc.

Speaking of which, I'd prefer cut & paste friendly this:

$ redis-cli hostname:port

To slays me every time this:

$ redis-cli -h hostname -p port

</comment><comment><USER65> Naggum on UIs:

"this is my _workbench_, dammit, it's not a pretty box to impress people with graphics and sounds. when I work at this system up to 12 hours a day, I'm profoundly uninterested in what user interface a novice user would prefer."

Full post: [http://www.xach.com/naggum/articles/3065048088243385@naggum....](http://firstname.lastname@example.com)

<comment><USER66> A simple UI is not necessarily one a novice would prefer.

</comment></comment><comment><USER67> I agree with the author, and I think the idea is somewhat applicable to everyday tools like text editors. This is partially why I've switched to Emacs (Spacemacs/evil) after using "conventional" text editors like Sublime Text for ages. Although GUI of ST3 may feel nicer at times, the UI (in a more general sense of this term) of Emacs is far more logical and is definitely a lot of fun to use.

</comment><comment><USER43> Programmers can also benefit from the readability of proportional fonts. I like this article, but it is hard to read for reasons beyond the writing itself.

</comment><comment><USER68> It's amazing that Docker has not been cited in the comments so far. LXC, jails, zones, etc were around for some time. What changed things imo was the incredible simplicity of the Dockerfile and the tooling around it. Re-watch the first public demo: [https://www.youtube.com/watch?v=wW9CAH9nSLs](https://www.youtube.com/watch?v=wW9CAH9nSLs)

<comment><USER19> I find docker increasingly complex and frustrating, at least for the pretty common use case of isolating dependencies for development. See vagga for an example of simplicity. There you have no daemon, no file permission conflicts, a simple way to run commands in containers and more

</comment></comment><comment><USER69> ...and some people drive complexity by design: be complex to be consistent (resistance is futile). I've seen that in big orgs where managers like "achieving" consistency (yay), even if developers are wasting time and money to adapt to cumbersome systems. Sometimes I see the same in communities, hype can promote a bad solution, while the lack of advocates (and time) can kill a better one.

</comment><comment><USER70> It's not just simple UIs, though -- As a programmer, I generally need to be able to dig down through the code and figure out what's going on behind the scenes.

This means that the implementation is often just as much the UI as any other aspect of the program. Simple implementations are just as important as simple UIs.

<comment><USER52> That's why redux is really nice - it's ~100 lines of code at its core.

</comment></comment><comment><USER71> The other benefit of simplicity - on top of the wasted time and learning - <USER3> reducing the opportunity for mistakes.

Misunderstanding of what's happening (or more commonly what is not happening) with some API endpoint due to an overly complex - often over-abstracted - design can be a very expensive mistake.

</comment><comment><USER72> This article reminds me as a designer how Hacker News (and Reddit) could use a face lift. I have a hard time reading the small text and identify in the listings that what's a link and what's not. :/

</comment><comment><USER73> Yes, all programmers are the same; none of them have different needs or desires.

<comment><USER74> To me, it's clear the author means, "Programmers are not different [from other types of computer users]; they need simple UI's [too]."

You seem to be interpreting it as, "Programmers are not different [from each other]; they need simple UI's [that limit their expressiveness]."

I guess? Honestly, I'm not really sure where your comment's coming from. Please elaborate.

</comment></comment><comment><USER75> I would _love_ a UI for my httpd.conf :)

Trillions of checkboxes with cryptic names and gigantic tooltips to dispay the detailled documentation (plus the zillions of relevant StackOverflows for the real-life bugs).

Nope, that's just sarcasm. Sometimes the best UI is a conf file, a web browser and Google.

<comment><USER76> What you're describing is a _GUI_ or Graphic UI. A conf file is a UI. As is a library or service API which is what he's discussing.</comment></comment>


Python proposal: add immutable (persistent) dictionaries - <AUTHOR> https://www.python.org/dev/peps/pep-0603/ <comment><USER2> This is the kind of ad-hoc PEP proposal that could be completely avoidable if there was a generic modifier or initialization/declaration construction for declaring a variable as constant. So incredibly simple, so incredibly useful that it's hard to believe that it hasn't been accepted yet (it was proposed).

<comment><USER3> A const declaration only ensures that the variable always points to the same object, not that that object is immutable. For instance in JS:

const foo = {};

foo.bar = 1;

<comment><USER2> That depends on the language.

</comment></comment></comment><comment><USER4> Something interesting to note is that Python's ContextVar (introduced in Python 3.7) is a persistent dictionary.

[https://www.python.org/dev/peps/pep-0567/#implementation](https://www.python.org/dev/peps/pep-0567/#implementation)

</comment><comment><USER5> Nice I like having persistent structures available. Then I don't have to safeguared against unintended modifications.</comment>


How academia betrayed Aaron Swartz - <AUTHOR> http://www.michaeleisen.org/blog/?p=1254

<comment><USER2> Why does the font size change from sentence to sentence? What bad typography.</comment>


What is the better way to start my career: Uber or Zenefits? (2014) - <AUTHOR> https://www.quora.com/What-is-the-better-way-to-start-my-career-Uber-or-Zenefits?share=1 <comment><AUTHOR> BTW, I have seen another post saying that the original Quora poster decided to work at LinkedIn in the end. I wonder if this is true or not.</comment>


The black-white wealth gap is unchanged after half a century - <AUTHOR> https://www.economist.com/united-states/2019/04/06/the-black-white-wealth-gap-is-unchanged-after-half-a-century <comment><USER2> > The mean of black household wealth is $138,200—for whites, that number is > $933,700

I think these numbers are inflated, for both African American and European American households, by including the 1% in these numbers. If we just use the upper middle class and below the number would likely be more like 175K for whites and 45K for blacks with home ownership and higher wages (even for the same jobs) being the big differentiators.

The article does a good job recounting the devastation that unchecked derision and segregation can cause - a us vs them frame of mind. In Tulsa Oklahoma the wealthy black populous was envied by the white community, and they were looking for reason to lash out given the rich black community shattered their conception of reality. As a black software developer I can tell you that shattering someone conception of the world is a very dangerous thing. I've faced insults and diminution of my work, everything from the rare few who hold certain concepts. Its hard to say anything because those in the workplace who aren't racist will still aid and abed those who are because that person may be a long time friend and ally. Such was the case in Tulsa.</comment>


Is it safe to keep Bluetooth always enabled in my smartphone? - <AUTHOR> <comment><USER2> It will drain your battery

And, depending on the model, OS release, and your preferences/settings, might be open to unsupervised pairing / file system spelunking

<comment><AUTHOR> That's what worries me. I want to keep a smartwatch paired with my phone all the time so I can get _silent_ notifications.

<comment><USER2> If your phone is _good_ , it will only pair when you tell it to

Some older Android, Windows Phones, possibly iOS (not 100% sure), and Blackberry had some exploits around Bluetooth

More-or-less any current phone (with current updates) _should_ be safe from that.

Key being: it needs to be kept up-to-date</comment></comment></comment>


Google has a problem retaining great engineers? Bullcrap. - <AUTHOR> http://thunk.org/tytso/blog/2010/11/29/google-has-a-problem-retaining-great-engineers-bullcrap/

<comment><USER2> "...the value Google is getting out of my work is worth many multiples of my total compensation. And that's a position that every engineer should strive for, since that's how you can be confident that you will remain gainfully employed."

As an entrepreneur, something about this statement bothers me... something about all the value I create getting skimmed off the top and taken away by someone else. Yeah, that's probably it.

But if you just want to do neat engineering work, then, sure, I get it.

<comment><USER3> But that's not really what's happening.

A skilled engineer who focuses solely on engineering will produce much better work than a skilled engineer that also has to focus on /marketing /sales /investors /accounting /facilities /IT /management /HR

Either a small fish in a big pond or a big fish in a small pond.

Edit: Also consider that you may be a person that can produce a lot of value specialized, but practically no value when juggling all the above items. You'll find that if you can produce a lot of value at any level then you can negotiate from a position of power.

<comment><USER4> With a name like johngalt I would think you'd be supporting his argument ;)

<comment><USER3> Atlas Shrugged is a fun fantasy, but in reality there are many different valuable specialties. It's all too easy to dismiss anyone that doesn't do what _you_ do as worthless.

That said I do agree that a very small number of people in any organization are responsible for the lion's share of the productivity and are inadequately compensated for that.

</comment></comment></comment></comment><comment><USER5>
      They are about business model discovery.
      So if you are fundamentally a technologist
      at heart, whose heart sings when you're
      making a better file system, or fixing a
      kernel bug, you're not going to be happy
      at a startup.

There are plenty of storage startups in Silicon Valley that would be happy to pay someone to do filesystem work.

Web 2.0 startups are not the only game in town. There are plenty of other companies at which to do serious engineering work.

<comment><USER6> Of course, but why go to those if you can do the same work at Google and actually be sure they'll be able to pay you more then you need to life comfortably.

<comment><USER5> Because at least at the startup you have the possibility, however remote, of getting FU money and never having to answer to anybody you don't like, ever again.

And besides, if you're that good, you don't really have any worries about getting paid what you're worth.

<comment><USER7> The whole FU money is mostly a fallacy. If you really love filesystem hacking, and you live in Silicon Valley and are really good at it, you already never have to answer to anybody you don't like, ever again. If you don't like your boss, you can quit, and do this 50 times if you want.

And people shouldn't work for a "possibility, however remote." That's called playing the lottery and is generally foolish.

</comment></comment></comment></comment><comment><USER8> Okay, so Google has a problem retaining the subset of great engineers who're also entrepreneurial.

That's still a problem.

<comment> brown9-2 Where does the author say that?

He is claiming that the startup life is for people interested in entrepreneurship, not technology. If their attrition rate truly hasn't moved at all, then I don't see how one can say there is a problem retaining any subset of people.

<comment><USER8> The author didn't say that, I said that.

We'd need more data, but obviously the attrition rate could remain constant for the whole while changing for some of its parts. Perhaps Google has gotten better at retaining non-entrepreneurial engineering talent, while getting worse at retaining entrepreneurial engineering talent.

<comment> brown9-2 _Perhaps Google has gotten better at retaining non-entrepreneurial engineering talent, while getting worse at retaining entrepreneurial engineering talent._

But you aren't really basing any of this on any facts or even statements by involved parties, are you? This is just theorizing that maybe their rate is worse in some spots. Maybe their rate is even better among this last category. What is the point of idle speculation like this?

</comment></comment></comment></comment><comment><USER9> FTA: "A startup is totally the wrong place for me."

There are startups out there that depend on superior engineering for their living. Off the top of my head, this guy would do very well at Heroku, Dropbox, RethinkDB, Clustrix and FlightCaster.

</comment><comment><USER10> From the perspective of working on file systems, I don't see a viable way to innovate and monetize. I completely see the OP point of view, from his perspective. I disagree with the conclusion though.

It is true that a lot of the big startups aren't innovating in technology. They are innovating in the business model space. But that doesn't mean you can't create some innovative technology to build a startup around it.

</comment><comment><USER11> In Sweden, Google has aquired Marratech and Global IP Solutions. Both are all about hardcore codec innovation, not business model discovery. Google was licensing tech from GIPS long before they aquired it. If big companies are where heavy tech is developed, aquisitions like those would never happen.

NB. Another Google aquisition from Sweden was Trendalyzer, Hans Rosling's visualization technology famous from his TED talk, making Sweden the country with most Google aquisitions in Europe, Middle-East and Africa.

<comment><USER12> It's a tie with Germany (allPAY,bruNET,Neven Vision Germany )

<comment><USER11> Ok, so let's make it per capita :)

</comment></comment></comment><comment><USER13> Google, like almost any other company of sufficient size, has a problem retaining great engineers who prefer smaller companies. Those preferences are not about the false dichotomy between "engineers" and "entrepreneurs". Mr. Ts'o enjoys a job in an established company where he can be paid well, work only on specific technical problems, work reasonable hours, etc. That's a fine choice, and the right one for many. It is, however, still exactly that: a job. People who start companies are not often looking for another job. Mr. Ts'o should be thankful that is so. Had Larry and Sergey taken his advice the company for which he works would not exist.

</comment><comment><USER14> The following sentence is very not true and quite misleading:

> Similarly, you don't work on great technology at a startup. .. They are > about business model discovery...

If that is true, then why do technology startups exist at all? Isn't discovering business model very much connected to discovering new technologies (new, more efficient ways to solve problems)? In other words, if a technology startup is not planning to invent something, then it not should probably exist in the first place.

It is true there are some Web 2.0 startups which are not about technology at all, but these startups are anyway not looking for great engineers.

<comment><USER15> I emphatically disagree. At least for most "technology startups".

Technology startups are just startups that require technology to operate. I've worked at some successful ones. And they really were about finding the right business model. We needed good technology people and there were fun technical problems. But really they were about finding business models that fully used the technology, and not about the technology itself.

That said, there are some _real_ technology startups. They look rather different. For instance I know employee #7 at SpaceX. There is no question that that company is really about the technology.

</comment></comment><comment><USER16> Reading the article title I immediately thought of those leaving Google for Facebook. This IS happening. They're doing it to catch the FB IPO.

OP mentions this topic but mostly talks about his view, which I get. On the other hand, I've spoken with plenty of ex-Google employees who've left because Google is getting so large and has so many 20% projects that it no longer feels so entrepreneurial being at Google and so they leave. These are employees that don't care about a business model and just want to see their projects see the light of day.

So, Google has a problem retaining great engineers? Sure, it doesn't apply to OP, but that doesn't mean it's bullcrap.

</comment><comment><USER17> I find this article misleading, Google certainly does not have problem retaining talents joining early stage startups. Those talents probably joined Google pre-IPO and funding their own startups now. The problem for the late Googlers is that they and their uncles all want to join the multi-billions dollar pre-IPO "company". And yes, their scale is big enough and affect millions, and the up side is, one day they can move on to be entrepreneurs.

<comment><USER18> Not everyone who participates in an IPO makes millions you know. Especially those who join in the later stages of a startup's lifecycle, the combined effects of (a) dilution, and (b) increasing stock valuation means the lottery payout diminishes very steeply. And in the case of Facebook, where there have been a lot more opportunities for stock to be sold pre-IPO, that means there are more opportunities for the stock valuation to be established. This has impacts for what the company can offer as far as stock options are concerned, which influences the upside opportunity.

Furthermore, given the huge amount of attention and hype about How Facebooks Success Is Assured, a lot of the "pop" in valuation that took place pre-IPO has probably already taken place. People who expect that Facebook will have its valuation (its market cap is currently estimated at $41 billion; Apple is $219 billion; IBM is $157 billion; Dell is $22 billion) "pop" by another 10x post-IPO will probably be sadly disappointed. And if you don't get that "pop", those stock options won't be worth all that much.

Which is one of the reasons I really don't believe the stories of $3.5m and $6m retention offers. It would simply be insane to make such offers, because the payout for someone jumping from Google to Facebook at this point, roughly a year before when people are guessing Facebook will IPO, are nowhere near that large (after stock reserved for the 5 stages of VC investment, and the founder's stock, and stock already issued to other employees, not to mention the shares that you know, need to actually be sold to the public, the number of options that could be granted per employee won't be that high). And, I'm pretty confident Google isn't insane. Furthermore, if Google was doing this, it would be bleedingly obvious on the quarterly 10Q statements it has to file with the SEC. So if you really think this is real, try doing some digging in the 10Q's 2-3 months from now.

</comment></comment><comment><USER19> Since Theodore brought this up: "(And those stories about Google paying $3.5 million and $7 million to keep an engineer from defecting to Facebook? As far as I know, total bull. I bet it's something made up by some Facebook recruiter who needed to explain how she let a live prospect get away. :-)"

I'm pretty sure it's real. Someone who either posts on here or who is frequently submitted -- I think piaw, or something like that? -- is an early Google ops person. Anyway, on piaw's blog, he or she mentioned that he or she had personally spoken to a G employee who got a counteroffer within 20% of the 3.5MM. So perhaps Theodore should be a little less sure of himself. Sorry for being vague, my memory is a little hazy, but I've read this in the last 2 weeks.

Also, he's doing something much closer to pure infrastructure work, so of course fewer -- but not zero -- web startups will be interested. That being said, I think it highly unlikely there are no jobs in SF / valley for highly experienced linux kernel file system devs.

Edit: link I referred to above [http://piaw.blogspot.com/2010/11/counter- offer-conundrum.htm...](http://piaw.blogspot.com/2010/11/counter-offer- conundrum.html)

"People asked me yesterday if the Techcrunch $3.5M story was true. I said it was believable, because while I wasn't involved in negotiating that particular counter-offer, I had some role in assisting someone land a counter-offer within 20% of that number some time back."

<comment><USER20> Of course it's true, I read it on the internet!</comment></comment>


Ask HN: How you pay bills b/w DemoDay and getting VC funded? - <AUTHOR>

Since YC only gives a little bit of money that is supposed to last you until Demo Day, and it is a known fact that it can be a while until you get the actual check from an investor, how are founders supposed to pay bills during that time if at Demo Day they have not yet established a revenue stream higher than their costs? <comment><USER2> One planned way to mitigate this is to work a steady job for a while. Save a bunch and then dive in. You know exactly how long your savings will last.

Though a bit different from your question, I just read a story about Airbnb on how they funded themselves selling something at a fundraiser or some such.

Sure money is a good lubricant; but it doesn't stop someone who is really after something.

<comment><AUTHOR> I'm not stopping or planning on stopping, I'm just wondering from a money management point of view.

Seed is supposed to last you till funding, but I guess the idea here is for it to last you till Demo Day.</comment></comment>


Columnar Storage - <AUTHOR> http://the-paper-trail.org/blog/columnar-storage/ <comment><USER2> I worked on a columnar database engine deployed on commodity Linux clusters in 2001, initial release 2002. This was at Sensage. We built a very fast DB engine that could store log data with 40x compression over traditional RDBMSs and ran log queries much more quickly than commercial DBs could at the time. I think we were too early.

Current Sensage company blurb about the event-data warehouse: <http://sensage.com/content/clustered-columnar-database> and [http://sensage.com/content/why-columnar%E2%80%A6not-row- base...](http://sensage.com/content/why-columnar%E2%80%A6not-row-based)

Patent work: <http://www.patentgenius.com/patent/7024414.html>

The core engineering team was CTO + 3 engineers. Best engineering experience of my life. I wasn't involved at the lowest DB storage level, the guys who did that did a great job.

Michael Stonebraker, technical advisor to Sensage, learned from the Sensage mistakes and built Vertica.

<comment><USER3> Sounds like Impala could use your talent. You should talk with them.

<comment><USER2> Thanks for the pointer! Looking at Cloudera's jobs board, most tech-heavy work is in SF or Palo Alto. I live in San Mateo, convenient to both of those, but ... I'm likely leaving for the North Carolina RTP area soon.

<comment><USER4> Cloudera has an office in RTP (Raleigh) as well: [http://www.cloudera.com/content/cloudera/en/about/contact- us...](http://www.cloudera.com/content/cloudera/en/about/contact-us.html)

</comment></comment></comment></comment><comment><USER5> When I hear columnar storage, I can't help but remember all the stories my friends have told me about kx systems (I'd love to share them but my memory is so fuzzy that I wouldn't be doing them justice. Hopefully some of the HNers here can share some of theirs though!) [1][2].

[1] <http://kx.com/>

[2] <http://en.wikipedia.org/wiki/K_(programming_language)>

<comment><USER6> Get your friends to join HN and tell us?

</comment></comment><comment><USER7> Everything old is new again. I remember considering using Sybase IQ Multiplex (columnar engine) back in 2000 in my startup. Just like "nosql" was all the rage a few years ago, bringing memory of the Pick databases of yore.

</comment><comment><USER8> Google's Dremel[0] also belong in this category.

[0] <http://research.google.com/pubs/pub36632.html>

</comment><comment><USER9> ((Morcane and diwa, you are [dead]. Consider creating a new account.))

</comment><comment><USER10> possibly dumb question; what's the difference between columnar storage and a bunch of row-major tables with an id column, and one column of data?

<comment><USER11> The biggest advantage of a pure column-oriented DBMS comes from having the positional information indirectly available without the requirement to store this ID information. During query execution the required position lists can then be generated.

In addition. If you considere the record format of traditional row-oriented databases you will see that the overhead of storing a single attribute record is rather high. Since with column-oriented DBMS its all about IO performance (Disk/Memory, Memory/CPU) such overhead can diminish the advantage.

Thus typical column stores tend to use only single strings of sequential memory to store the data. This can even be enhanced by applying dictionary compression and as a result only storing integer values. And modern CPUs are good in processing lots of them.

</comment></comment><comment><USER12> Is this effectively a read-write inverted index?</comment>


Show HN: ShittyMVP.com – Quick and Dirty MVP with a Money Back Guarantee - <AUTHOR> https://www.shittymvp.com/ <comment><USER2> I tried doing something similar a year ago but had a lot of trouble finding the right type of customer who needed an MVP. Being able to start fresh and move quickly on a new idea sounds like the perfect kind of work :) Just curious how many projects you've done so far with this model?

PS. love the simplicity of your site. it shows me you know the true meaning of MVP!

<comment><AUTHOR> Yeah, getting client is tough. Especially when the targets here don't have anything out yet.

ShittyMVP was just launched so nothing yet with exactly that model, however there are a lot of lessons here from my previous work with clients.

Thank you for the compliment :)

</comment></comment><comment><AUTHOR> I founded this after bumping over and over again into (usually non-tech) people just wanting to get something out, _now_. It's a lot harder for non- technical people to test the waters, and it often includes a lot of grinding work just to get a freelance team up and running.

The thing here is that I work with the clients on their MVP scope so it can fit our offering ($5000 & 30 days), a thing that usually makes the MVP better, more focused.

Since I operate so fast some things can't be promised (like code quality or a spec document), but that's what the money back guarantee is for.

Hopefully this will help more talented people release and test stuff instead of sitting in a room writing specs.

<comment><USER3> that money back guarantee is going to hurt :(

</comment></comment><comment><USER4> Every client and manager I've ever worked for wanted their thing done as fast as possible. No business person I've met actually understands technical debt, let alone factors it into decision making.

I work with my clients to manage these trade-offs, and most of them opt for low cost, high speed, low code quality. I still don't charge a flat fee or offer money back.

<comment><AUTHOR> As I mentioned in another comment, the price is indeed fixed, but the work is not -- if client's initial request is too much work for ShittyMVP's offering I will advise to remove features. If all of them are crucial to the MVP, and they rarely are, I'll recommend trying other freelance options (such as yourself).

</comment></comment><comment><USER5> I'd like to start a similar site, but where people start a project (MVP) and we add dev steps that they can fund one step at a time (i.e. in $250-500 chunks). initial consult fee is $200 to lay out the general budget and tasks to get to 100%.

</comment><comment><USER6> can you explain your process after payment ? Like design, how do you collect requirements that are in scope ? etc.

What language or frameworks do you use ?

Do you at least try to write good code ?

<comment><AUTHOR> Design is very simple -- creative work is usually the most time consuming and so what I do is have an aesthetically pleasing yet _very_ simple design.

This depends on the project, but mostly (in no particular order): Node, Python, Angular, Vue, NativeScript, Ionic.

Yes, I most definitely try to write good code -- that statement is an underpromise because code good is simply not the focus.

</comment></comment><comment><USER7> Nice! Do I get my money back if the MVP isn't shitty?

<comment><AUTHOR> You get your money back for any reason! I can understand why you'd be angry if we break the shitty promise.

</comment></comment><comment><USER8> Interesting idea! How do you protect yourself against people always requesting for a refund? It seems this could be abused, no?

<comment><AUTHOR> That's right -- I ask for money upfront to know they're serious. I then deploy the final product to a dev env and don't deliver until they say they want to keep it

<comment><USER9> But what happens when you deploy it to production, they grab the code, and 29 days later they request a refund? Do you void the 30-day guarantee when they sign off for a production deployment? Or is that 30 days included in the 30-day development period? (Sneaky, sneaky…)

<comment><AUTHOR> There isn't a 30-day money back guarantee, just a money back guarantee. It is indeed voided on production deployment

<comment><USER9> Oops--I guess I misread. Cool idea, regardless. Good luck!</comment></comment></comment></comment></comment>