I could do that in a weekend (2016)
danluu.com
danluu.com
This sort of thing happens all the time in professional software development. Sometimes it is a waste of time, e.g. people rewriting things in a new language/framework for negligible benefits, but a lot of it is a necessary part of developing a polished app.
I guess we'll just have to wait until people get used to the idea that the Web is an interactive document format, not a replacement for the GUI. I'm hoping the modern SPA trends pass into the void like the Macromedia Flash UI trends did.
You ever hear how in certain cultures, Mom's food is the best? Now, of course there's nostalgia involved. A hint of home can make your taste buds sing just a bit louder. But also, even for a 'simple' meal, there are so many options a chef can make that subtly change the meal.
For example, looking only at one ingredient, you can end up with a dizzying amount of options. For example, do you use chicken thighs or white meat, sear it first or let it braise, brine it or salt it right before going on, use a jar of pre-ground spices or add your own concoction of 5 spices? Each of those is a choice, and only one set of choices ends up with Mom's chicken cacciatore.
In software, any good UX is usually the result of thousands of intentional choices. It takes trial and error and research and actually time spent using the damn thing to figure out the tradeoffs involved in many of those choices. Just like it usually takes new chefs dozens of crappy, burnt, lifeless meals before developing the taste required to make those tradeoffs effectively.
Just had the semi-shocking realization that the cross-section between those cultures and the cultures where moms are stay at home is quite large.
Like, people will get weepy over canned veggies. Personally I think nostalgia is the most significant ingredient here.
It was just plain creamed corn with condensed milk. But it was also the best thing I had ever eaten.
She was very confused. As was my grandmother. And my mom. None of them understood just how important that “granny corn” was, despite the fact that it was straight from a can into the pan to be heated a little, and then put into a bowl for me.
I heard that story time and time again, for decades.
Association is a huge part of impression and memories. That’s why smell is such a good trigger for emotions, because it is very primal and connected so closely to those parts of your brain that are involved in association.
I’ve worked in digitalisation in the public sector of Denmark for quite some time. A few years ago I was part of the group who redefined our national principals for architecture in municipality IT systems. The whole thing is called rammearkitekturen which translates directly into “the framework architecture” and without getting into too much details it was made because we had 98 muniplacities times 300 average IT systems ways or defining what a person was. Which made buying and integrating IT hard. Rammeaekitekturen still hasn’t fixed that, but that’s not what I want to talk about.
One of the things to come out of this mindset was how to design an IT system for eldercare. Where there used to be a physical folder with a printed note containing all the “Moksly may attempt to hit you during showers and this requires two caretakers” and so on as well as hand written notes for day to day things, medicine used to come in little sorted bags clearly labelled “MORNING” and so on, and every morning people would get a printed list of their route that was adjusted for coworkers who were off sick and so on, and that was pretty much it. Today we have multiple different billion dollar systems to handle those basic things, and after two years of being used they still can’t handle differences between day and night-shifts or giving call-in temps the correct sorts of data access.
Instead of having two planners and a subscription to a pharmacy for the sorted medicine bags, we now employ almost 50 people as full time support staff to operate this system as well as throwing endless amounts of resources after project managers, lean consultants, educators and so on to get this system to work.
When polled everything single citizen and caretaking employee replied that the old non-digital systems were better. At no point has anyone asked whether or not it made sense to digitalise this area or if it makes sense to continue trying to implement it.
So I do think that it’s sometimes reasonable to wonder just what all those people are doing in some organisation. Because sometimes systems have a way of making themselves important to the organisation without actually being important to the organisation.
I've been working on a product which everybody was convinced had Gantt chart functionality. Said functionality was using the venerable Math.random() top to bottom, with nobody being the wiser.
That way it's "just" "Pull up the most recent documents relating to or updated for patient Doe, Jane" or "What has changed in the medications prescribed in this district?"
The Document Management System would still manage all the PDFs or caretaker notes, but would (eventually) be searchable, and would still support the primary workflow of "I just want to see all the recent documentation for my patient" or "This is caretaker Alex's most recent route assignment document".
1. Specialized, monolithic systems. These try to do everything for everyone and usually end up devolving into the 12-month (or longer) release cycles. "Monolith" doesn't mean monolith vs microservice in this context. Just that the system is trying to be all encompassing. This is the norm. It rarely works well because it massively increases the cost for change (money, personnel, and time) even for what should be minor things (Oh, you need a custom report? We'll get it to you next year.).
2. Generalized, flexible systems. A document management system like you discuss would be one potential solution. These tend to be more data-oriented (sharing a common database or a common set of databases) with potentially custom front ends. The front ends tend to permit flexibility for the user, including generating their own queries and workflows. These usually work out better, but are not that common among mega corporation or government digitization efforts.
The former is easier to "sell". You get to manage a massive contract, it looks more productive than it is. The latter tends to be more grassroots, an internal effort. The former is highly visible, the latter is nearly invisible.
Related, people tend to overvalue work that appears difficult and undervalue work that appears easy. The second approach tends to make modifications "trivial", so the managers ask, "What are we paying you for?"
There is merit in the question, but I think the answer is less "the core product is a lot more complicated than it seems" and more "a big software company with lots of eyes on it can make even more money by hiring more people to create more products that are ancillary to the core product."
This is a common downfall of engineers who try entrepreneurship before they’ve gained managerial or operational experience. I’ve lost count of how many entrepreneurs I’ve talked to who got something running on an Arduino or Raspberry Pi and think that they’re one step away from a successful business. Really, the hard work is only beginning.
Are you saying that sending messages back and forth involves a lot more complexity that you don't see or that Slack does a lot more than just messages?
> Are files, screen sharing, video calls, etc. still "just messages"?
I wouldn't think any of those as messages that a basic message-only client would have.
I guess that's the distinction I was after - was the person I replied to talking about all the complexity of a basic message-only client, or were they talking about the complexity of all the stuff beyond that.
SlackOps is a really big thing. Making slack the glue across variety of operational systems to coordinate the activity of a team and allowing that team to communicate about it, provides a ton of value. And importantly, allowing this to happen organically with non-IT staff creating their own workflows (in the way that people invent alls sorts of min-apps in spreadsheets) is pretty powerful.
I'd be curious how many users were like us - messages only?
Now the client on the other hand...
I would love them if it was actually noticeable when someone else creates a thread to which i'm supposed to contribute...
No. It's over complicated. They need a better solution.
Perhaps you only use Slack as a followup to meetings/todo items. We use it for all communication and the workflow is about opposite: someone raises an issue, someone or everyone discusses it, someone takes ownership and it turns into their TODO item.
> This reminds me of a common fallacy we see in unreliable systems, where people build the happy path with the idea that the happy path is the “real” work, and that error handling can be tacked on later. For reliable systems, error handling is more work than the happy path.
Is there a name for this fallacy? I think this isn't merely a familiar anecdote, but something that points to the root of why armchair architects think things are easier than they actually are.
I often think SpaceX was able to move that quickly because they could learn from decades of experience of NASA and others what works and what doesn’t.
Differently from Google search, the hard thing about Uber is not the software. What makes a lot of sense, but leaves the question of what are all those people doing there, what the article answers, but the answer is not trivial in any way.
Fully agree, and would extend to any social organization. One of the most important aspects of organizational efficiency is managing the signal/noise ratio of internal communications. We now have the ability to turn effective bureaucratic protocols into material reality with automated information systems.
The organizations, whether private or public, that best tackle this problem will come out on top on the 21st century, regardless of ideology and historical advantage.
Unfortunately it takes quite a bit of orchestration on higher level of abstraction and having well organized management.
Many years ago I built a search engine for a very big discussion board website, which had hundreds of millions of messages. Keep in mind back then a powerful server had 2GB of RAM and a pretty slow CPU and HDD, so it had to be distributed across multiple shards to work fast enough, and there was no Elastic Search back then, so it really was hard work, plus getting the ranking and quality tuned was a huge effort. Of course when we launched it people responded with "I don't get what the big deal is, why can't you just run a SELECT WHERE LIKE query and get it over with over the weekend?". It was hurtful at first but then I realized how ignorant the person making such a statement is about the problem.
I mean, those Volvo XC90s are damn slick, but somehow my local pizza place delivers hot tasty stuff on time in an old Fiat Seicento. I think the pizza quality would suffer if the owner invested in a more reliable and better car.
Eyes read best when content is a few hundred pixels long. Content should be centered etc.
It's pretty terrible as it is
Opera pioneered this interface, AFAIK, and even had one-click toggle buttons for both author and user styles (as well as images), but most of today's browsers don't make this functionality transparent and available. I suppose you could do via dev tools?
For a simple change like what you're asking, perhaps even changing browser's font settings would suffice?
I find it's quite a bother to have to do all the CSS necessary for good reflow on a number of devices, so I too just have everything just spill to the ends, and just do reader mode on devices. But I don't really know much CSS apart from the really basic stuff, and haven't ever sat down to see how it would be done.
max-width: 700px; margin: 0 auto;
This would make it look great on pretty much all screens.
Just holding up a book to my screen, 700px is about the width of the text in a mass-market paperback. But the reading distance for a screen is much larger than the reading distance for a book, of course. And hardcovers or trade paperbacks have wider text columns than that, of obviously, and are generally somewhat nicer to read than mass-market paperbacks... though also often get held at slightly larger reading distances.
You hold a book closer to your eyes though than your screen.
Both have about the same line length, as you point out, but the book's font is smaller. The website font is much larger - to make up for the greater distance between the screen and your eyes.
I think 700px would be wide enough, 800px would also work.
From what I've read, going wider than about this at around a 14px size font and it becomes increasingly difficult for the eye to track between lines.
On a phone, a max with of 700 or 800 px obviously wouldn't apply since the phone screen is smaller.
On this site, I usually zoom in to 150% to 200% on my computer to make the font size large enough to comfortably read.
If the book's font is smaller, but the lines are the same width, that means more words per line in the book, yes?
And each line is taking a larger fraction of the visual field, since the book is closer to my eyes.
Basically, if we assume books are somewhat optimized for ease of reading (and to a large extent they are), websites should be aiming for the same angular sizes as books. The reading distance is larger, so the physical sizes should be larger: larger fonts and wider lines...
(A famous example from the other direction was when Uber re-engineered a querying service to better fit the use case, where several HNers and a Medium article showed why their re-invented wheel was worse than an off-the-shelf solution that they just weren't using correctly [2].)
If you can't satisfy that, then this feels like a fully-general rejection of any claim that an org has over-complicated a problem or has unnecessary bloat, and/or that no one can criticize until they've personally worked (for n months) at the org. Which itself would be hard to defend.
[1] Based on my "Scylla-Charybdis"/Goldilocks Heuristic: http://blog.tyrannyofthemouse.com/2015/12/the-scylla-charybd...
Something like Postman is a bet on enterprise tooling for APIs, both building and integrating with them. Looks like Postman has gone beyond their chrome extension, and leveraged that to add more a bunch more features. But even if all that was easy enough to build, the investment is really about the trend and the business ability to capitalize on the trend. VC investment is always more forward-looking than the current product state.
Thing is, I could do that for myself and I would be the only user and I would never turn it into a company.
Because what devs usually say they could do that product in the weekend - but usable only for themselves. While turning software package into successful product that a lot of people would use is totally different story.
Just like playing piano for your friends on the weekend or guitar by the fire that takes maybe couple weeks of training. To become a pop-star well that is just different pair of shoes.
It's just that many times these comments are on threads about the fundraise itself. "Why is Postman worth $B when I could build that in a weekend?" is completely missing what it takes to build a business.
Previous discussions:
0. Dan writes an article about marginal employment decisions, which cites 1. Alex Clemmer wrote (http://blog.nullspace.io/building-search-engines.html) about building a search engine to compete with Google, who cites 2. John Peebles, who wrote (https://peebs.org/2014/01/04/we-need-viable-search-engine-co...) about the urgent need for a viable competitor to Google, saying:
> I wonder if we haven’t all been hypnotised by the complexity, much of which is marketing hype, and have missed the enormous opportunity that exists right in front of our noses. Does the next search engine have to be as big, involved in as many things, employ as many people, and fight on the same footing to be accomplish the goal of providing a counterpoint to Google?
This article was upvoted fairly well on on HN (https://news.ycombinator.com/item?id=7011472), though the top comments are all in agreement this is not a simple task. This zeitgeist, along with Dan's personal experience on the subject, is why he wrote the article using Google as the example.
its been a few years but i knew of multiple alexa-100 sites that were all running on just two 4 core servers(this is back when alexa was a useful measure of size, mind you). managed essentially by the hosting company. so "scale" is not always directly linked to traffic, i would think complexity dictates the need for more engineers rather then size.