Less stress, more productivity: working fewer hours is good for you and your boss - <AUTHOR> https://codewithoutrules.com/2016/08/18/productive-programmer/ <comment><USER4> > _Long hours: "It's 5 o'clock and I should be done with work, but I just need > to finish this problem, just one more try," you tell yourself. But being > tired it actually takes you another three hours to solve. The next day you > go to work tired and unfocused._

> _Shorter hours: "It's 5 o'clock and I wish I had this fixed, but I guess > I'll try tomorrow morning." The next morning, refreshed, you solve the > problem in 10 minutes._

I have too much experience with this. I remember when I was self-employed I humble-brag tweeted about my production deployment ~15 minutes after starting work. A friend of mine asked why I hadn't just deployed last night and the quote above was my first thought (in addition to the fact that you should never deploy to prod then go to bed). I was done with work, so I stopped. It avoids hitting that "grind it out" phase where you're lucky just not to do more harm than good.

<comment><USER5> This has happened way more times than I can count. Spending hours staring at a line of code, up all night. Wake up next morning, and it's a simple spelling mistake I've missed. Grinding out work has never been productive. Mistakes happen when you're tired. This applies to study cramming as well, and it's completely pointless. Study as much as you can, until your NORMAL bed time, then stop and get a full nights rest before the test.

Side note, it's no wonder these big games come riddled with bugs these days. Pushing developers to the extreme during crunch time, just to meet a deadline. There is NO WAY they are doing everything correctly.

<comment><USER6> I think it does sometimes work, which is why at last I fall back to it.

Grind out fix.. 90% success rate, average time to solve - 1 hour.

Sleep and fix in the morning.. 100% success rate, average time to solve - <USER2> minutes.

Clearly better to sleep but if something needs fixed NOW... then it's time to grind I guess...

<comment><USER7> What about the 3rd option, getting two tasks done?

\- Grind for 1 hour and assuming 90% success rate, finish the task 9 out of 10 times

\- Sleep

\- Finish another task in 15 min with, again based on your assumption, a success rate of 100%

In start-ups there is usually a near endless list of tasks to solve so this would be the most productive approach. Again, based on a lot of assumptions.

[edit: formatting]

<comment><USER8> Except that success rate was assuming that you did get the rest you needed, mainly from leaving at a reasonable time. Staying and grinding directly contradicts that, so you're not going to be rested and well in the morning, and you're not going to have the success rate of 100%.

Basically, you just advocated for crunch time and death marches. Things that are known to not work.

</comment></comment></comment></comment></comment><comment><USER9> Just this week, I've been collecting feedback from my team. Some of the most powerful I received was, "Since you took over, I feel like I've gotten more done with so much less stress and extra hours. Until you came in, I didn't believe that we could really have work-life-balance and be MORE productive and now I know we can."

Having been in companies where my approach has been called everything from "lazy" to outright "damaging," this feedback was both rewarding and validating.

Edit: For those who are in jobs where you're putting in those long hours, I can tell you there are managers out there who believe in the message here. I have three of them working for me right now and I constantly reinforce the philosophy of working sustainably. Don't settle for less than a manager who respects you the person--not just you the engineer!

<comment><USER10> Totally agree. We're running a team with engineers working 20 hours a week. That seems like about the amount of "productive engineering time" that most people have in them in a week, regardless of how many hours they actually spend working.

It's a bit of an experiment, but I have to say that I'm really happy with what it's doing for us. Our engineers are still quite productive. Their work life balance is good, so we can avoid burnout (though this will take a long time to actually prove). And, finally, it gives us a _huge_ competitive advantage when it comes to hiring top quality engineers.

<comment><USER11> Neat. Checked out your web site and really like your philosophy! I'm a solo consultant going into my tenth consecutive year. I too have found that >20 hours definitely throws off the balance. It's still a work in progress, but that 20 hour mark is about what consider my level of useful (high impact) hours.

I understand what you do for employees of your firm, but how do you apply your philosophy to yourself (and the other principals)? Client work is one thing, but there's plenty of non-client work too. Particularly in a small firm!

<comment><USER12> I'm also a solo consultant (really just a contractor), and I've been working 20 hour weeks for the last month or so. I'm finding that I actually don't feel productive enough, mainly because I'm working for a small unlaunched startup, and they are really itching to launch. I mean, I'm still feeling productive for those 4 hours, but when I'm in "the zone", I can focus for much longer. When I'm work on a personal startup or side project, I often spend all day on it, maybe with a few breaks for food.

I'm holding fast to my 4 hour days, but I'm starting to feel like it's not ideal to be the sole part-time developer on a project that needs to launch soon.

But I suppose this could probably be mitigated if they hired another 1 or 2 developers.

<comment><USER13> I used to be a consultant and went through periods of Uber productivity for 30 to 40 hours a week. When I was in this phase I let my productivity and creativity drive my total weekly effort. Being in the flow feels good and leads to better solutions. But it is not sustainable week after week. Now 30 years later, at 62 years old, I just can't sustain more than 20 hours per week of coding, software design or pre project planning for complex projects. I now find productivity and pleasure doing some of the administrative work managing my team and reporting up. Actually have a new boss and he is asking for lots of data and more. Right now his questions seem valid so it is not a burden. If he learns and grows great. If his information needs don't die down in a few months this may be a burden.

Edit: typos. Need coffee.

</comment></comment></comment></comment></comment><comment><USER14> I started a consulting/services company a few years ago, and this year was finally in a position to start hiring. I'm a big proponent of this type of thinking, so while I couldn't offer the best salary, or the best benefits - <USER3> could offer a better work/life balance. I knew it was a win-win for us and the new employee.

We landed on a 36 hour work week. 8-5 Mon-Thurs, then 8-12 on Friday. We had more applicants than I ever dreamed of, and scored a great hire that was coming from the 70-hr-a-week startup life. Everyone's been extremely happy over the past six months, and I don't feel like I'm missing out on any productivity what-so-ever.

<comment><USER15> This is great, but isn't that a 40 hour work week? Most places consider 9-5 to be 8 hours (lunch and coffee breaks count towards the total).

If we accept this convention, your workers are technically there for 9 hours a day for 4 days and 4 hours on Friday. Still clocking in 40 hours.

Nevertheless, I'm sure they enjoy their half day off on Friday and the work culture that put it in place.

<comment><USER16> lunch and coffee breaks count towards 8 hour work day? usually 8 hour work day = 4 hours work before lunch and 4 hours work after

<comment><USER17> I count my work day as "time spent commuting, working, or anything else keeping me from spending time at home with my family."

<comment><USER18> Me too. It isn't time off just because I'm not producing for an employer. If it requires me to commute, walk, etc. and it is work related, I classify that as working hours because those are the hours of my day that are given to my employer, even if they are not getting an immediate, direct benefit from those minutes. I realize I am not being paid for that time, but it doesn't change the fact that I am doing that instead of something else.

<comment><USER19> If you are salaried, you are being paid for that time. The effect is to reduce your effective hourly wage.

I quit my last employer because the extra 2 hours required for commuting and dressing (both of which incur unreimbursed expenses) on top of my 9 billable hours was taking up a significant chunk of my compensation.

</comment></comment></comment></comment></comment></comment><comment><USER20> > One programmer I know made clear when she started a job at a startup that > she worked 40-45 hours a week and that's it. Everyone else worked much > longer hours, but that was her personal limit. Personally I have negotiated > a 35-hour work week.

Wow, what a depressing time to be employed. The old standard (35 hours) is now considered a "short" workweek, and only the most desirable employees have the leverage to request it. Not to mention stagnant wages, rapidly rising costs of living, and off-hour availability expectations.

How did we end up here?

<comment><USER21> >How did we end up here?

MBAs and MBAification.

When management is treated as a generic function that can be performed by a particular _class_ of people in any field rather than the most senior expert practitioners in their respective fields, this is what happens.

You get insecure authoritarians who latch on to (utterly wrong) metrics as a means of "understanding" what it is their subordinates do without actually understanding what it is they do.

With software developers it used to be SLOC (thankfully that died). With GPs it's "number of patients seen". With teachers it's standardized test scores.

There's a direct correlation between managerial technical ineptitude and insistence on working long hours.

<comment><USER22> Measurement is hard.

<comment><USER23> If you need a book to really drive that point home to someone, check out "Seeing Like A State" by James C. Scott.

<comment><USER22> Have you seen "All Cared For By Machines of Living Grace" by Adam Curtis? I wonder if Curtis used this as source material? It's the same basic idea, although it may appear that Curtis generalizes to a different view of the fallacy underlying all this.

The ghost of Otto von Bismarck laughs every night.

<comment><USER23> Thanks for the suggestion - the summary info I read makes it sound like a lot of intuitions I don't have fleshed out well enough to explain thoroughly. It's likely going to be either great or maddeningly off in subtle ways. Either way I'm interested in watching it.

<comment><USER22> Adam's films are .. just essays. They're flawed and informal, but the basic ... bones of his ideas are intriguing and stimulating.

I am glad I could reciprocate with something because I really like "Thinking Like a State" ( after my rapid-read treatment, with a slow read TBD). It encapsulates so many ideas I've never really seen bundled before, along with some that require further digging. I would not be surprised if "Thinking.." wasn't an influence on him.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> >There are companies where this won't fly, of course, where management is so bad or norms are so out of whack that even a 40-hour work week by a productive team member won't be acceptable. In those cases you need to look for a new job, and as part of the interview figure out the work culture and project management practices of prospective employers. Do people work short hours or long hours? Is everything always on fire or do projects get delivered on time?

I have _never_ figured out how to ask this. It always feels like I'm asking, "I don't like to work much, is that ok with you?"

<comment><USER25> Its tricky. I usually wait until near the end of the interview, after I've asked a bunch of questions, especially when they say "do you have any other questions?" Then I say, "Hmm. What is work/life balance like at X?" I used to wait until the end of the full-day interview, but many times found out I'd wasted a day on a company that I wouldn't want to work for. So now I do it at the end of the phone screen.

<comment><USER8> How do you ensure that they're answering it honestly, though? Or, less maliciously, that they're answering it with something in line with what you'd think is a decent work life balance?

<comment><USER25> Its not really in their interest to answer dishonestly: if I take the job and it turns out the work/life balance sucks, I'll leave, and they'll have wasted a lot of time & effort on me.

Also, the people I'm asking are typically engineers, they're not inclined to lie about things like this, and they're not expert spin doctors. Plus, when I go for the full day interview and talk to many people, I'll ask many of them about it.

</comment></comment></comment></comment><comment><USER26> Having spent a lot of time both as a manager and as an individual contributor, here's the rub (at least for programmers): software developers are a classic market for lemons. The bigger the org and the more operational complexity the more space there is for poor developers to hide out and draw a pay check. But even at a small scale it's remarkably difficult to measure productivity actually.

Therefore, what you need is intrinsic motivation. You need engineers who really care about solving the right problem at the right time in the right way. 35 hours or 70 doesn't matter if they can't get that right, and it's very hard to have management that is qualified to make that judgement on people (especially as an org grows and management becomes a full time job). So the problem is that given this opacity, finding someone who works 70 hours a week is a better proxy than someone who seems excited about a 35-hour work week—the former are people who are clearly driven whereas the latter are literally everyone. It's far from a good metric, but perhaps the best one available to the pointy hairs of the world.

Speaking from personal experience, it wasn't until I had a kid that I found out what I could do in a 40-hour week. Once I had that time constraint, it forced me to be more efficient in a very deep and fundamental way from the core of my being. When I was 25 I would hit 5pm and think to myself: I still have another 8 hours to solve this problem before bed. Perhaps this is post- hoc justification, but I think that makes sense when you are just starting out and not really competent yet. Once you've passed the magic 10k hours or whatever, I think turning over problems in ones subconscious can provide a lot more of the value. So sleep / exercise / meditation can all help elevate your performance far more than extra hours—but only if your brain knows what it's doing.

<comment><USER27> In my experience the lemons have no problem working 70 hour weeks; they weren't working that hard to begin with and know that they need to appear productive since they can't be productive. Whereas employees who are productive are tired after 35 hours or want to get home and work on side projects.

Long work hours actually select for lemons.

</comment></comment><comment><USER28> Of course every personal experience is just anecdotal but since I only work 24 hours a week I feel able to educate myself, do sports, feel more healthy. Before that I worked one week full and one week only 4 days repeatedly and I really got the feeling that coming in on Mondays after a short week was so much easier. I felt more relaxed and satisfied because I could do other stuff on the weekend than trying to catch up with buying things and all that organizational junk you have to do as an adult.

Now I work 6 hours a day, 4 days a week and I don't take long breaks anymore. I stopped to read blogs or news at work after lunch, I just work. Would be really interesting if this is just me or if it could be scientifically proven that working less is more.

<comment><USER29> May I ask what industry you work in?

<comment><USER28> I support researchers of the humanities by developing different services like registries and restful apis. But you know, everything has it's cost. I am definitely underpaid but at some point I decided time > money for now.

</comment></comment></comment><comment><USER30> Even better, drop hours as a metric of work. Offer the flexibility to work whatever hours are most productive... and find a boss who doesn't care whether that is 40 or 20, as long as he gets the value he expects from your time.

After all, employment is a business contract. You are given money in exchange for the value you add to the organization. Not hours... value.

<comment><USER24> I have heard managers respond that if you can get your responsibilities done in half the time, you should be getting more responsibilities.

<comment><USER31> I'd respond that I'd expect to be getting a requisite increase increase in compensation.

At least I hope I would.

<comment><USER32> Years ago I casually met an owner of a small software company who happened to be hiring, and I was looking for a job. He asked if I was cheap and I instantly answered 'why, are you?'

Normally I don't think of witty things like that to say until about a week after the event.

</comment></comment></comment></comment><comment><USER33> I was expecting the list of sources at the bottom of the article to be a mile long. Not a single one. Hot damn, so much broscience and red herrings.

<comment><USER34> To be fair, the title wasn't "New study proves that..." or even "Scientists say...". It was very clear that this a blog post written by a dude sharing his own experiences and anecdotes. Not some "proof" that life is better with less hours.

</comment></comment><comment><USER35> Its the Theater of Productivity, similar to the TSA. You can see Meyer's approach to productivity was ultimately just as successful as the TSA on secutity. Yeah doing an early stage startup it could be on the side of a day job so yes you are going to inevtiably put in a lot of hours for $0 doing a startup. But for regular businesses that are well established such as Yahoo this isn't productivity its Productivity Theater in the same way the TSA are Security Theater.

</comment><comment><USER36> I think the key is less-stress and not shorter hours. Meetings, especially long ones, induce stress.

I've tried reducing hours (as a freelance remote developer). I cut my working hours to 25 per week from somewhere around 60ish per week. (And I could afford losing out money)

At first, I felt I was missing something. I thought it was the money. After being completely off work for a month, I realized I was missing the people (Slack chats, meetings, fire-fights)

When I started back with another client, working just 25 hours per week was much much much harder. None of these worked: 8x3days, 4x6days, 6x4days, 5x5days. Few weeks I could not even complete 15 hours, and other weeks I was over-working. I was still stressed. Finally, what worked was odd - (10-12 hours)x2.5 days. So I ended up working a bit more hours than I wanted to. It was proven again that it takes time and focus to pickup momentum and costs a lot more to loose it frequently. And I still work on my other stuff totalling to about 45-50 hour work-weeks and still feels much less stressful.

<comment><USER32> Have you tried working when you feel like it (or when you really have to), and just not working when you're not in the mood? I had a three year period working freelance and it was most profitable and fun. I have no clue how many hours I was doing but for the last six months I only worked a few hours a week because I was able to automate most of my work.

I'm doing a startup now and this lifestyle wouldn't be acceptable to my partners so it's back to a 9-late schedule plus weekends. I'm nowhere near as productive and strongly feel like I'm accomplishing less, but to go back to working how I like would just cause conflicts.

<comment><USER36> Unfortunately, I do not have such luxury. I do have flexibility within a work- week. i.e. I could be working on client project on MTW or FSS or in between, but I prefer doing much work within Tue-Fri. Fortunately, I have been with one very good client working on challenging stuff yet does not have tight deadlines. It is a risky strategy to stay with just one client - but I am not worried too much about it now. Since its billable hours, I don't see automation would help reduce my hours - it increases efficiency though.

I tried a startup with some partners and recommended a flexible schedule, but unfortunately partners got too flexible and it never took off. It is better to slog and make others do that in a startup.

</comment></comment></comment><comment><USER37> There are certain jobs where it may not work, but from what I've seen places I've worked, 40hr workweeks seem like a holdover from some, in my opinion, truly bizarre cultural expectations. I mean, at some offices I've worked people are basically shooting the breeze for at least 10 hours at the office a week with coworkers. Some of them don't like being at home with their families and so seem to think work is a way to get away from their responsibilities outside of work. I'd rather have that 'time bullshitting with coworkers' to do things I like to do not at work.

Is this some holdover from previous generations of just wanting to pressure everyone to do what they had to do? Sure, sometimes things need to get done, but alot of jobs aren't saving lives or doing much amazing, but "hit that deadline or we're going to die" is almost the implication made in business in the US in my experience...

Hopefully we'll stop this work addiction some day and realize lots of things can get done without making people be behind a desk an arbitrary number of hours per day...

<comment><USER38> > Some of them don't like being at home with their families

I've noticed this as well. The people who worked the longest hours did so because they didn't like going home.

</comment></comment><comment><USER39> Henry Ford originally found that 40 hour work weeks were optimal for productivity for his factory employees. Before this, they only had one day of rest and were generally overworked and inefficient. I think the work of a factory worker is vastly different than the work we do today behind a computer, especially programmers where your brain power is everything. It would be interesting if a big enough company were to do some proper research on the most efficient working patterns of a programmer today.

</comment><comment><USER40> Recruiters. Find me a company that believes this, and I'll actually reply to you.

<comment><USER41> Ask them on the interview.

It will be a red flag to dysfunctional companies who think you don't want to work hard.

Employees at good companies will be proud that they don't overwork.

<comment><USER42> This is true in my case. We work 8 hour days, 5 days per week, and I always mention it when interviewing candidates. We're proud of the fact that we can ship a successful product without working the team to constant exhaustion.

</comment></comment></comment><comment><USER43> In my experience, in order to maximize the productivity in creative work and still work 40 hours, you have to pick the best 40 hours out of a 168 hour time frame:

\- If it means you work '13 hours 20 minutes' on Monday Wednesday Friday, so be it.

\- If it means you work '5 hours 45 minutes' Monday thru Sunday, so be it.

\- If it means you work one way one week, the other way the next week, so be it.

\- If you work best in the middle of the night, so be it.

\- If it means you work 10 hours everyday for 52 days straight, and take the rest of the quarter off (39 days!), so be it.

The problem is, we have to do this thing called 'work/life balance' in which we are at work 9 to 5, whether we feel fresh or tired, and have to forget about work for the remaining 128 hours.

Combine that with the need for in-person interaction with the team, the boss, and what not, it gets worse.

IMO you can't have it both ways.

</comment><comment><USER44> Yeah.... not so much for me. I'm going to give an alternate point of view.

To become world class at something, you need to be obsessed. You need to put in as many hours as possible and just love what you're doing.

"Oh but you won't be as effective after 8 hours of work!"

So what. Let's say I'm only 20% as effective after 8 hours. I'll take it -- 20% of the last 5-6 hours of the day towards my craft over 0% doing 'normal' things (drinks on the patio? Pointless travelling? Whatever my fellow annoying millenials like to do).

This is the kind of mindset you need to reach the top of a field. And it should develop naturally, you should really want it. Whether it means outdoing everyone at your company, getting that prototype done two months earlier, closing more leads, getting that tricky piano passage, whatever.

If you love what you're doing, more is more. Because you probably can't help yourself. If you feel like working more, just do it. Don't let normal social expectations hold you back, especially if you're young, because you only get so long to become great at something.

I'll finish with one final caveat. Figure out what level of sleep, exercise, and nutrition your body needs to sustain your desired work habits. Get those right ASAP, keep trying modifications, and realize it's different for everyone's unique biology. I like 8 hours of sleep a night, weightlifting 3x/week at 45-60mins each, and a certain amount of protein and certain vitamins (and coffee of course, ha). You'd be surprised how these 3 lifestyle factors can make such a huge difference in your energy levels and hormones -- one can literally become a different person!

<comment><USER45> The theory here is that not only are you at 20% for the last hour: you will be at 90% at the beginning of the second day, 80% on the third and so on. Of course the percentages are totally made up, but it is obvious that there is an amount of work from which no single instance of rest can cause a complete recovery. If the results of such unrest are cumulative, then there must exist some amount of work that is less productive than working less for any kind of sustained endeavor.

The problem is we have no real way of measuring personal productivity, so we have no real way to find where the optimal point is for any individual. Society as a whole has chosen 40 weekly hours as a standard for mostly orthogonal reasons. In aggregate, the number is probably wrong. But it seems crazy to me to argue that there's no (sizable) fragment of the population that would not be as productive, or more so, with less than the 8 hours they work now.

</comment></comment><comment><USER46> How does a company like SpaceX fit into this? They seem to promote the opposite and are seeing some pretty amazing success. Do they succeed because of or despite working long hours?

<comment><USER47> Maybe I've seen it in the past but I don't remember it now -- what is their employee turnover rate? I imagine they have no shortage of applicants willing to put in 70 hour weeks until they burn out, just to get that name on their CV.

<comment><USER48> [https://www.reddit.com/r/spacex/comments/309990/why_does_spa...](https://www.reddit.com/r/spacex/comments/309990/why_does_spacex_require_such_long_hours_instead/)

<comment><USER49> This sort of thing makes it hard for me to respect Elon Musk. He is, personally, doing great things, but I wonder if his overall effect on the world is negative in the long term because he's promoting some views that I find very harmful. So many people around him, who admire him, yet he feels like a one man team.

</comment></comment></comment></comment><comment><USER50> The most (professionally) successful persons I know worked very hard at least at some point in their life. For instance, I know tons of professors that pretty much work all the time. Same thing with former schoolmates working in finance now.

I'm not saying it's the road to follow, and obviously, not all careers are comparable, but I think that in order to reach their full potential, people have to (and can) work a lot.

<comment><USER51> Just a few days ago I read an article or blog entry - which I may even have found through a comment on HN? - where a successful important person described the reunions with the people he had studied with over 20 years.

At first everybody was so amazingly successful, great wife, then great kids, all doing very well, financially too. But after 10 years with each reunion less and less people showed up. Those who were missing had no wife and family left and didn't want their old pals to know how their personal lives had faltered.

You only mention careers...? Please report overall long-term life success that includes the family :)

Also, since you mention finance, while they personally benefited, and their industry did too, what about the rest of society? Does the latest microsecond computer trading algorithm really benefit mankind overall?

So to summarize, the questions I have are about 1) individual success not just "career", "financial" and "short term", and 2) that individual success from the perspective of society.

<comment><USER50> As I said, I didn't want to mean that everybody should work hard or that professional success is the only important thing. But I think that in order to succeed in a competitive field, one has too work hard and it's definitely doable.

That being said, I'm an advocate of less working hours and more vacation. I worked in the US for a couple of years, and this is the one thing that made me go back to Europe. Free time is the most important thing in my opinion.

<comment><USER49> I wonder if that just selects for people who can work longer without losing productivity / sanity. That doesn't strike me as normal.

</comment></comment></comment></comment><comment><USER52> There is no science here what so-ever. Just a bunch of feel good rah rah BS about working less hours and getting more done. Some fodder to go to your manager with I guess.

Who said that 35-40 hours is optimal? How can you even quantify it considering every job is different. I've had jobs where 50% was brainless support so i'd work 10-12 hr days and my brain was totally fine to keep going. Some jobs come with inevitable social BS that will take 50% of your time anyway.

The problem is that management and developers have different incentives. Managers [in more cases then not] are pushed by executives to justify their worth and deliver results.

Developers want to create, but also don't care as much about the bottom line. They want to have a life outside of work.

It's that simple. Let's not go pretending like anything beyond 40 hours takes 10x time to get done because it simply doesn't. It's just an empty thing to say like "you should give me a raise because of inflation".

There are plenty of people working their own startups doing 80-100 hr weeks and getting shit ton done. Does it mean that you should do this at a corporation? Maybe not, maybe yes. It all depends on the trade offs either side is willing to make. Managers will of course be incentivized to push for more productivity per employee.

Places such as Basecamp take a stance against this incentive gap. They're actively working at making employees take more vacation, sleep better, and have a better work life balance. This must improve employee morale and retention. No idea what it does to bottom line or employee paychecks.

As a manger I've had people that worked 40- hrs and delivered amazing results. I'd never even think about caring how many hours they've put in. Then there were others that worked more but delivered a mound of technical debt or nothing at all. They were usually the ones most vocal about working too many hours. There are very few people out there that can come in, get straight to work, and deliver quality. Simply making a blank statement that they will do more by working less is silly.

<comment><USER53> I agree strongly with the idea that "40 hours" is just as made up as "15 hours" or whatever. We need actual data to draw any conclusions here. Similarly we haven't explored all the ways we can make people more productive either. Maybe if the employees who feel tired after six hours could take a long nap mid-day they'd be able to work 12 hours a day at a high level.

That said I'm on the work what you feel comfortable working and as long as goals are being met then it doesn't matter.

<comment><USER54> The 40 hour work week comes from Ford. It is optimized for factory workers. Data for creative/makers would be interesting to see.

<comment><USER55> "The eight-hour day movement or 40-hour week movement, also known as the short-time movement, was started by James Deb and had its origins in the Industrial Revolution in Britain, where industrial production in large factories transformed working life. The use of child labour was common. The working day could range from 10 to 16 hours for six days a week."[1]

It is the second time this month that this misconception about Ford comes around, I am curious to know where it comes from.

[1][https://en.wikipedia.org/wiki/Eight- hour_day](https://en.wikipedia.org/wiki/Eight-hour_day)

<comment><USER54> Interesting! I remember first reading this on Wikipedia a few years ago. either I'm misremembering or the article has changed since then. Here's one article about Ford's influence on it: [http://www.politifact.com/truth-o- meter/statements/2015/sep/...](http://www.politifact.com/truth-o- meter/statements/2015/sep/09/viral-image/does-8-hour-day-and-40-hour-come- henry-ford-or-lab/)

A quick Google search and there are a lot of others like this. Thanks!

</comment></comment></comment></comment></comment><comment><USER12> Right now I'm working 20 hours per week as a contractor. It's beautiful.

My hours are also pretty flexible. If I'm really in the zone, I can work a 10 hour day. That's what I did today. I started at 3pm, had a break around 7pm, and I just finished what I was working on at 2am (30 minutes ago).

Yesterday, I wasn't feeling motivated at all, so I just ended up taking the day off and doing something else.

I'm living in Thailand, so normally I'll work from 10pm until 2am, so I have overlap with clients in the US. I wake up at 10am, and it feels like I have the whole day to do whatever I like.

I'm earning less money, but I'm somehow saving much more than I did in San Francisco.

<comment><USER56> The implication of those hours is that you go to bed pretty soon after finishing work -- how easy do you find it to wind down on a schedule?

<comment><USER12> Yes, that's right. I take about 30 minutes to read or watch something, but I usually find it very easy to fall asleep.

</comment></comment></comment><comment> atom-morgan Imagine trying to convince a slave master that freedom, in the long run, will lead to more productivity on a scale that they can't even imagine. I believe working fewer hours is a modern day version of that.

</comment><comment><USER57> This also applies if you are in university. Your ability to learn is directly related to the quality of sleep you have gotten. If your school believes "sleep is for the weak" and makes labs due at 6am, please realise that this is bullshit and find tools/habits to enforce a different discipline.

<comment><USER58> I remember when I realized in my introductory circuits class that all the problems were just puzzles, and sleep beats the hell out of studying when it comes to preparing for puzzles.

</comment></comment><comment><USER59> I've noticed this when playing chess, which is I guess a pretty good way to measure one's analytical capabilities and concentration. When playing against a computer in the evening after 8+ hours of work my games are significantly weaker; I can't anymore beat the same game level that I easily win in the morning. By looking into game stats I've noticed that in the evenings I make significantly more mistakes, don't see good moves, make hasty decisions more often, etc.

</comment><comment><USER60> Sounds nice, but maybe some evidence would be good?

<comment><USER61> "Why does working longer hours not improve the situation? Because working longer makes you less productive at the same time that it encourages bad practices by your boss. Working fewer hours does the opposite."

<comment><USER60> This is evidence? Working fewer hours than what? There is obviously a point where your productivity drops off, but that doesn't mean you are producing less work overall.

What I would like to see is tangible evidence. Perhaps analyzing Jira for several companies to see the effort put into projects vs the overall productivity. Maybe set the baseline at the 40 hour week and analyze a few different chunks like 30, 35, 45, 50, and 60 hours per week. Without some sort of analysis like this all we have pure conjecture, and no way to understand where a reasonable cutoff should be.

<comment><USER62> I agree. Things like having the weekends free and getting enough sleep are really important for having a sustainable working life. But that does not mean working 35 hours per week is a must or 40 hours is a natural limit, for example 9 AM to 8 PM from Monday-Friday is a 50 hour workweek and easily sustainable. The norm in industries like banking, big law firms or management consulting is more like a 60-70 hour work week and while it is obviously not desirable, there are many people who can do it for many years.

</comment></comment></comment></comment><comment><USER63> I thought this was about working fewer hours than full time, but apparently it's about working no more than full time.

<comment><AUTHOR> OP here: I've actually worked 27 hour work/week, but that's a hard sell given we're in an industry that's trending towards insane hours as the norm. So partially this is just me trying to explain than normal hours are actually better (which is I admit a sad thing to have to explain). But less than full time is even better, yes. For me at least I think 30 hours/week would be the ideal.

</comment></comment><comment><USER64> Tired is the worst time to code. There are other things you can do to be productive - but try not writing mission critical code when you are exhausted.

</comment><comment><USER65> I agree with that. Last ~1-2hours in job I feel bored and everything is not so productive than it should.

I would like to work in/create place where engineers work for ~30h a week including lunch/coffee time.

I think with that kind of work everyone would be happy and could easly balance work/life

</comment><comment><USER66> The key to this article at a macroscopic level is the willingness to quit when the manager or culture are unwilling to adapt to your fewer hours proposition. We can positively change the industry for everyone by uniformly following this guidanace.

</comment><comment><USER67> I find that, for boring tasks or everyday work, this is true. I cannot use "turbo mode" for too long.

But if there is something really challenging in which I plunged in, and at the same time I am getting results, it will break the rule. I think much of what written here makes sense: [https://en.wikipedia.org/wiki/Flow_(psychology)#Conditions_f...](https://en.wikipedia.org/wiki/Flow_\(psychology\)#Conditions_for_flow)

Also, if you really want to be productive, it's not about sleep, but about having very defined and organized tasks, so you limit the number of open decisions you have to take in a day.

</comment><comment><USER51> [http://dilbert.com/strip/1993-10-26](http://dilbert.com/strip/1993-10-26)

Does anybody have time to comment on the article submitted by OP? :)

</comment><comment><USER54> The best "full time" work environment I experienced was a 9-5 week with morning/afternoon 3-hour coding blocks (no interruptions tolerated) and an hour lunch. The other hour was spent in the standup, email, one-off conversations and blogging/community work. We were a highly production and creative team.

</comment><comment><USER34> This is one of the reasons why more telecommuting/remote work is "better". Since you've got no boss looking (literally) over your shoulder, you can't be judged on hours. Then things like output or project completion actually bubble to the top as most important.

</comment><comment><USER68> Bottom of the article has a link...to learn from your mistakes (perhaps because you worked too many long hours.) We can get emailed a list of his mistakes. [https://softwareclown.com/](https://softwareclown.com/)

</comment><comment><USER19> Good article, but I don't see where it addresses how working fewer hours is good for your boss (though, you can try to read in to it). The article even says that it (working less hours) won't work at some companies.

</comment><comment><USER69> I thought this was about reducing it from 40h to 30h or so, but it was about fighting for the 40h themselves. I am in Japan now and things are really crazy here for my friends.

</comment><comment><USER70> I've been fortunate enough that my employer encourages people to find the patterns that work for them. Now that I've been there a few years, I've been taking greater liberties on when I come and go. Some days I just wander home at 3pm because it's just not happening. Other days I'm there 8-8 and skip lunch because I'm so excited to see a new feature work. I've never been so productive or happy.

</comment><comment><USER71> For much of the article the author is saying that with less time to complete a project you now use your time more wisely and you'll get the same amount of work done in a shorter window. If that was the case then managers should instead add 20% more to every project. Now you'd be delivering 20% more with the same resources as before. Not buying it.

</comment><comment><USER71> For much of the article the author is saying that with less time to complete a project you now use your time more wisely and you'll get the same amount of work done in a shorter window. If that was the case then managers should instead add 20% more to every project.

</comment><comment><USER72> Hey, I know the guy who wrote this! As a boss, and in fact as the former boss of itamarst, I agree with this strategy. I want employees to produce high- quality work, to be predictable in their pace, to not get burnt out, and to be happy and pleasant to work with.

</comment><comment><USER73> Not for Non-IT

</comment><comment><USER74> I agree with the fact about cutting out meetings but I don't know if I agree with everything here.

While its easy to say "Just leave at 5pm and come back refreshed" is easy to say, I found personally to have learned to most on the days when I've worked until 2am really digging into a problem and getting it fixed. I also have found that the best people I've worked with have a similar get it done attitude. Obviously this isn't sustainable but I think required from time to time.

I also think this lacks the notion of "how much do you want to move up vs stay in your current role". If you don't have any desire for more responsibilities than this applies, but I think if you want to move up/learn new skills, reducing the hours works against you.

I guess I follow the mantra of, "The first 40 should be productive and for the employer in the role I was hired for but I should spend additional time on top of that learning new skills"

<comment><USER29> And I have found that tired employees make huge mistakes on customer critical systems. I have also found that some people are extremely successful working insane hours. They have the capacity to, either it's their personality or they're still young and single. To think that applies to everyone is the issue. Not everyone can work tired and produce good work or do a good job. Would you want someone tired working dangerous machinery just to get something done? We would all be against that.

Yes, it's pretty well established that to move up hours must be put in. The reason this topic comes up time and time again is because no one asks the question why nor do they prove that these hours translate to better work or more productivity. I've seen insane hours in third party consultants. They mess up. A lot.</comment></comment>


Introducing SproutCore Touch 2.0 Beta – A Gesture System For SproutCore - <AUTHOR> http://blog.sproutcore.com/introducing-sproutcore-touch-2-0-beta-a-gesture-system-for-sproutcore/ <comment><USER2> SC2 is shaping up nicely, looking forward to seeing more details at tomorrow's meetup!

</comment><comment><USER3> FYI, I added a demo section to the blog post with links to an Instagram demo.</comment>


How to Speak by Patrick Winston - <AUTHOR> https://youtu.be/Unzc731iCUY <comment><AUTHOR> Patrick Winston's How to Speak talk has been an MIT tradition for over 40 years. Offered every January, the talk is intended to improve your speaking ability in critical situations by teaching you a few heuristic rules.</comment>


In search of the perfect JavaScript framework - <AUTHOR> https://dev.opera.com/articles/perfect-javascript-framework/ <comment><USER3> _> We want to apply values to variables and get the DOM updated. The popular two-way data binding should not be a feature, but a must-have core functionality._

Strongly disagree. I find one-way bindings and one-way data flow much easier to reason about. A little less boilerplate code is not worth mental overhead, cascading updates and hunting down the source of wrong data in my experience.

What _is_ important is _not updating the DOM from the code and instead describing it with a pure function_. React, Cycle, Mithril, Mercury do it, and it's time we get used to this. _This_ is the real timesaver, not two-way bindings.

`Object.observe` is the wrong way to approach this problem. If you own the data, why invent a complex approach to watch it, if you could update it in a centralized fashion in the first place? Here is a great presentation on that topic: [http://markdalgleish.github.io/presentation-a-state-of- chang...](http://markdalgleish.github.io/presentation-a-state-of-change- object-observe/). I strongly suggest you read it ("Space" to switch slides) if these ideas are still alien to you.

Even _Angular_ is abandoning two-way bindings. [http://victorsavkin.com/post/110170125256/change- detection-i...](http://victorsavkin.com/post/110170125256/change-detection-in- angular-2)

I, for one, welcome our new immutable overlords.

<comment><USER4> While I have been using React since it launched in May 2013 and I agree with a lot of what you said, using words like "right" and "wrong" doesn't help. React is a great way to write applications but it isn't the most mature library ever, and the junior developers I worked with had quite a bit of trouble working with it for a while because functional programming is so _different_. The ecosystem is filling in, things are great, but "you are wrong and I am right" harms as much as it helps.

<comment><USER3> Of course there isn't a "right" or "wrong" way. I'm sorry I didn't write it more clearly.

Approaches like jQuery soup or making SQL queries from PHP templates aren't "wrong" either. They are friendlier to beginner, too.

When I wrote "wrong" I meant "in my experience, inferior for building applications with complex stateful user interfaces and later maintaining them for a period more than several months in the face of changing requirements".

Also, I'm not talking specifically about React. Of course it has its own shortcomings. All I'm saying is that relying on `Object.observe` and giving out global state to all components to mutate is the same as using global variables throughout the program. I don't know whether it is helpful to call global variables "right" or "wrong" but I'd certainly stay away from them when there are ways to achieve the same without future maintenance nightmare.

</comment></comment></comment><comment><USER5> > "Abstraction is dangerous"

The fact that Javascript people keep saying this with a straight face is getting really absurd.

You _do_ realize Javascript is also just an abstraction, right? And that the browsers that run it also abstractions, and the operating systems, and the kernels, and even the hardware itself has multiple layers of abstraction?

"Abstraction is dangerous" is just fundamentally wrong. Abstraction is the only way we get anything done.

What you really mean to say is that bad abstractions are bad. But stated so clearly, it becomes obvious that it's a tautology. Well-designed abstractions that leak as little as possible are essential to everything we do.

This stuff matters, because instead of having stupid arguments over "how much" abstraction we want (which really boils down to 99 layers vs 100 layers) we should be debating _exactly what_ abstractions we want.

<comment><USER6> "Black boxes are dangerous" is maybe a more precise way of expressing the concept. I don't think the author literally believes you must be writing machine code.

<comment><USER5> If black boxes are dangerous then you really should be writing machine code. Which is absurd of course, and demonstrates that black boxes are a very good thing.

Javascript itself is a black box. It would totally suck if you had to know how it's implemented inside to use it.

<comment><USER7> Ok let me try. Bad abstractions are bad.

Additional complexity without additional functionality, increased dependencies without increasing stability, poor documentation and buggy implementations; strongly coupled things which have no business being coupled and overt assumptions on what kind of application you are writing and how you ought to structure it.

They have fundamentals which don't interact with anything else - events that won't be caught, arrays that use their own iterator, etc.

They decide to suppress language features like console logging and replace it using different names. You never learn this by reading the outdated documentation but by startling discoveries 45 minutes into what ought to have been a 15 second bug.

And let's not get started on how utterly useless the call stack or object inspector becomes.

They presume there are fewer coherent approaches to programming in a language then there actually are so they shoehorn you into writing things in one specific poorly documented, buggy, highly complex, inappropriate, monolithic, and fragile way.

One of the main arguments for the abstraction approach is that they assist average programmers like a golfing handicap. But the reality is that the quality of the programmers work remains the same - but now with the abuse and misuse of the language AND a convoluted abstraction. You are far worse off.

The historical problem is that these things despite all of these clear flaws become immensely popular - each one for about 6 months.

And then your business critical application gets locked in. Locked in to the hottest framework from 5 years ago.

Awesome

btw, I tweet about my hatred of this specific topic here: [https://twitter.com/frameworkhater](https://twitter.com/frameworkhater) ... I think a proper manifesto may be in order.

<comment><USER8> I can see all sides of the arguments here. I do love API's, but I hate "frameworks", especially when they consist of useless functions like

      function _MY_framework.enterprise.displayMessageInConsole(msg) {
        console.log(msg);
      }

That does something that would actually be easier in vanilla JS. All years of writing JS may have made me blind, but that's how I see most JS frameworks. Mostly useless.

That said, manipulating the DOM in JS is a PITA. I can totally understand why you would want to do it another way.

I guess the DOM is not meant to be manipulated with ... And breaks if JS is turned off.

I think in the near future in maybe 5-6 years we'll see apps that are a mix of Browser and Native. That has the protected environment like a browser, that ask for permission to use hardware features, that can be accessed through high level API's, have native performance and run by typing an domain address much like WWW.

</comment></comment></comment></comment></comment><comment><USER9> My theory is that, for much of the web, the perfect javascript framework is _no_ javascript framework.

Get rid of all the abstraction, local state, dependency injection, symbol management and so on. Take HTML/HTTP seriously and think about REST in terms of HTML rather than JSON.

That's intercooler.js:

[http://intercoolerjs.org](http://intercoolerjs.org)

Here's an image I tweeted trying to explain how to get there mentally:

[https://pbs.twimg.com/media/B9QNU- ZCQAECP-K.png:large](https://pbs.twimg.com/media/B9QNU-ZCQAECP-K.png:large)

Yes, it's a simple model. And no, it doesn't work for every app. But many apps would be infinitely simpler and more usable in a browser by using this approach, and almost _all_ apps have some part of them that would be simpler to implement using it.

<comment><USER10> As a developer that recently made the transition from FileMaker, which is very user-friendly but limiting, to Rails, I love the new possibilities and the fact that Rails provides nearly everything I need and comes with established best practices, but I'm always a little helpless when interactivity (without reloading the page) is required. The apps I'm working on (internal, business apps) mostly work perfectly fine with a document-based approach and most features can be integrated as simple CRUD actions, but from time to time I need just a little interactivity - like in a classic scenario of an order with several line items that needs to calculate and display totals in a form as soon as the input changes. It's that simple, no need for a framework, even most libraries feel overblown for that use case.

I looked at various data-binding javascript libraries, but they all seem like targeting much bigger problems than mine. So I resort to classic jquery, data attributes and ajax calls, but it feels very messy, like a hack not intended to work that way. It may be the fact that I'm new to this but it feels as if I'm missing something very obvious whenever I have to deal with that kind of very basic interactivity and dynamic. It's a simple form that temporarily needs to calculate and process inputs until the user saves the record and solving this seems way too complicated and messy. Are there any options for those simple cases and apps that otherwise would do just fine with a document- based architecture?

<comment><USER11> I found Knockout to be a great middle ground for when "I can do this in jQuery, but it's gona be messy" and "I'm building a SPA".

It hits the sweet spot between easy learning curve, abstraction, and interacting with the DOM nicely.

Sadly, it's not as hip as React/Angular/Ember these days.

<comment><USER12> I've also had a good experience using Knockout. I used it to add some interactivity to a largely static site, and then expanded its use to create a fairly complex management interface. It's easy to pick up with great interactive tutorials on the web site, and with component support in the latest version you can build some larger web apps.

Microsoft uses it their recent remake of their Azure portal; this page has a video on building large apps with Knockout: [http://jbeckwith.com/2014/09/20/how-the-azure-portal- works/](http://jbeckwith.com/2014/09/20/how-the-azure-portal-works/)

</comment></comment></comment></comment><comment><USER13> As long as your javascript framework is a micro framework and not a monolithic one, the abstraction does not make the project foggy.

Building the core and then using micro frameworks or components like react, jquery, etc leads to less walls as swapping is easier as time progresses.

You don't want to be caught high and dry stuck in years of monolithic to cleanup when the fad dies and at that point having abstracted away everything you need to know.

Outside of javascript, .NET WebForms and Drupal are classic examples of too much abstraction in monolithic fashion (those poor bastards stuck there - <USER2> man walking), Angular might be another. The whole time you spent building addendums and machinations to a framework, not building the core of what needs to be known.

If the framework changes everything you do and abstracts core logic or the systems you are building doing things without you being aware, it might be easy to start 90% but there are gonna be problems and eventually walls and walls against you.

The only thing that should be monolithic and the base is programming languages and platforms. Everything else should be micro components or messaging.

</comment><comment><USER14> It's a thought-provoking article, but I would also like to see something about React in it. It seems to me that React is a very pragmatic way to get around the global complexity-driven performance issues with DOM manipulation.

When we're coding, we're optimizing for a couple of different things, really. First is real-world performance (represented by slowpoke DOM manipulation). Second is programmer performance (represented by inappropriate abstractions). A lot of things we can do in Javascript to make programming less difficult and complex result in poor real-world performance, and vice versa.

But what do I know? I'm not by any stretch of the imagination a Javascript expert.

</comment><comment><USER15> I yet to find "perfect" JS framework. I bet, it will never happen.

Nevertheless, I have a favor to ask any framework developer out there - please, make it disassemblable and usable piece by piece outside of framework.

OP was right - sometimes i find some aspect of framework nice, but more often than not it is monolith part of the whole framework, which as a whole I dislike.

ps: current combination it seems to fit my mind workflow is Backbone (models + collections) + Ractive.js (Views) + Machina.js (for routing and defining "controllers"/states.) Although I am looking to use something else besides Machina.js in next project, as I want to have hierarchy now. And since it is all loosely coupled, I can replace parts.

</comment><comment><USER16> The whole "abstraction is dangerous" spiel is so wrong (imo) that I don't even know how to respond to anything that follows.

The primary complaint appears to be that abstraction eliminates your ability to operationally trace the meaning of a program. This is true, but sacrificing operational denotations only hurts if you replace it with nothing else— _and abstractions of general purpose languages are almost always more interpretable than the operational denotation of the base language itself!_

Of course, there are always places for poor abstractions. I am not talking about these. Abstractions which are intentionally opaque, have confusing action-at-a-distance, etc---you're bringing down the name of abstraction in general. "Leaky" is insufficiently demeaning.

A good abstraction will have its own semantics. These can be equational, denotational, operational, what-have-you but, essentially, these semantics must be easier/simpler/more relevant than the semantics of the base language they're embedded in. Otherwise why abstract?

So what does React give you? It gives you, more or less, a value-based compositional semantics. Components have some "living" nature (an operational semantics w.r.t. to state) but they're mostly defined by their static nature. Because you can build whole applications thinking only about the static, compositional nature of components you can take massive advantage of this abstraction.

Ultimately, _you do not want_ operational semantics for React. This is what gives us React Native, background rendering, and probably what will lead to sensible animations (in time). To define operational semantics, especially ones which have to look like or (worse) be identical to those of Javascript, would destroy almost all possibility of extension. At the cost of making things more complex and harder to reason about.

All so that you can just stick to "obvious" Javascript base operations.

</comment><comment><USER17> Where does react.js fall in this discussion? Or does it? Just reading a lot about react.js this week.

</comment><comment><USER18> > Abstraction is dangerous

True statement. Of course, it's _more or less_ true, depending on how much the abstraction you're using leaks. Few (if any) abstractions completely encapsulate complexity, almost all will leak. But there's a range. Some abstractions elegantly cover a modular portion of your problem space and do it so well you only rarely have to think about what's going on under the hood (and will even produce effective clues as to what's going wrong when something does go wrong). Some abstractions awkwardly cover only part of a modular portion of your problem space, require a high intellectual down payment to even start to use, have gotcha cases that chew up performance or even break things, and require continual attention to what's going on just to keep development going.

Most are probably in between.

I think this is what JWZ is talking about in his famous "now you have two problems" assessment of regular expressions. I don't read him as saying "regular expressions suck," I read him as saying anything but tools from the high end of the abstraction quality spectrum means now you have two problems: (1) the problem you started with (2) the problem of keeping the model/details of how the tool works in your head. Regular expressions are arguably in the (maybe high) middle of the spectrum -- they may not cover your case well (ahem, markup) and they can send your program's performance to hell or even halt it if you don't know what you're doing.

Now, they're also broadly useful enough in all kinds of development that the benefits go up with the costs and so they're probably worth investing in anyway, as part of a suite of other parsing tools/techniques. So I'm not bringing the topic up to bash them.

But to take us back to the topic, I might be bringing it up to question the ROI of popular JS frameworks, which, as far as I can tell, are generally not at the the high end of the abstraction quality spectrum, don't have the broad usefulness of regular expressions to recommend them, and may not even survive longer than a handful of years.

<comment><USER5> No, it's not a true statement. It's fundamentally wrong. Because if abstraction is dangerous, we should all be laying out transistors by hand instead of writing code.

People get so comfortable with their familiar abstractions that they forget they're still abstractions.

Taking the article as an example, even his "less abstracted" examples are _absurdly abstract_ , and I doubt anybody here can really say for sure how they work completely, underneath all the abstractions. That's a good thing, because it lets us get things done and express ideas in hardware-independent ways.

<comment><USER19> Abstractions are dangerous - if you abstract wrong, your code is potentially worse than the unabstracted version since it is easy to impose an abstraction where there is none, but a poorly abstracted component is harder to correct.

<comment><USER20> ANYTHING done wrong can be dangerous,abstraction or not. The problem isn't abstraction but "poor code",whatever it means. spec writers chose to go with the DOM,which is a poor API and it led to things like DHTML because DOM just sucked. It was clearly not made for what devs are doing with the web today,thus the need to abstract a bad API with a framework or a library.

I bet you don't write web apps adding DOM nodes to the DOM document.You're already using an abstraction if you're using any DHTML api.But you didn't know that.

</comment></comment></comment></comment><comment><USER21> The Knockout example in this article is a bit strange - Knockout is not a framework (it is explicit about this) - but besides that, Knockout components actually do allow the "framework" to decide when things are instantiated.

</comment><comment><USER22> One super simple framework is [https://github.com/techlayer/espresso.js/](https://github.com/techlayer/espresso.js/)

It's a bastard child of React and Backbone.

</comment><comment><USER23> I like the direction author is going. I have used similar methodology designing my applications (for mobile), simple, micro libraries, one way data binding.

[http://hn.premii.com/](http://hn.premii.com/)

[http://reddit.premii.com/](http://reddit.premii.com/)

* I have bunch of helper functions (UI and non-UI). Each function define in its own file and independent (easy to unit test). Personal library like jQuery but not a jQuery replacement.

* App is route based. One route to many controllers. Each controller is a page/screen on mobile.

* There is only one model (API) that interface with 3rd party library. API layer talks to 3rd party library to get data or gets data from server directly, caches data, etc. Provides sync (Cached data) and async (Cached data or fresh from server) interface to controllers.

* There is a app class or I call it a page manager. Responsible for managing pages like ordering, loading, unloading etc (Kind of big and complex 200+ lines of logic).

\- Decides which page to animate in which direction on mobile (Loading new page or going back).

\- Order of pages (Back button)

\- Passes events to its controllers

\- Decides which pages to keep in DOM, and which to remove.

\--- If you go from homepage to comments to profile page, all pages are in DOM.

\--- When you go back to comments page from profile page, profile page will be destroyed and controller will be notified. Same happens when you go from comments to home page.

\--- If you go to same comments page again, it will be loaded as a new page.

* Controller:

\- Each controller may have multiple CSS and templates

\- Controller uses its template to render

\- Using sync API to get data to renders page.

\- If sync API returns no data, renders empty page with loading, and makes async API call.

\- Controller are idle when transitioning (animating) from one page to another on mobile. (Very important for smooth animation)

\- Simple but fat controllers

\- Controller handles events, UI logic

\- Self cleaning so that browser can collect garbage when necessary

I package app using node/gulp. Anything that is not specific to page/app related, it becomes part of a helper library. Each app has its own model (Data layer), and controllers. I use micro templates, precompile using node for faster performance.

<comment><USER24> Thanks for creating hn.premii.com! About half my use of Hacker News is through your web app. I even wrote a little bookmarklet that turns all links on hn.algolia.com and hckrnews.com into links to your app when I happen to be browsing on mobile! And I'm always happy to find out you introduced a new feature (which I would like to see more regularly, not that I'm complaining!).

Alongside Alien Blue, your app is my most used app on my phone. Your work is very appreciated!

</comment></comment><comment><USER25> I don't agree with DOM event handling: setting events at every node comes with a cost. And I think you forgot to mention the performance issues with that approach and so now a days almost all frameworks prefer to event delegation.

I think author except in 1,2 points didn't bother to take side with performance aspects.

</comment><comment><USER26> > We all like simple tools. Complexity kills. It makes our work difficult and > gives us much steeper learning curve. Programmers need to know how things > work. Otherwise, they feel insecure. If we work with a complex system, then > we have a big gap between "I am using it" and "I know how it works".

One answer to this problem of opaqueness in abstractions is having a well defined denotational semantics. This makes it clear that something can work in one way & only one way (without the need to dive into library internals). I feel that Elm is doing a pretty good job of tackling this for GUIs and signals.

</comment><comment><USER27> I don't think people use frameworks and abstractions because they have a smoothier learning curve, or because they are simpler, but because of DRY. After repeating the same pattern twice, the programmer turns it into a module and abstracts it. After having a lot of modules, the programmer packages them all in a framework. This is good for the author of those modules and the framework, because he understand them, but not always for the outsider who just looks at the complete framework and don't know what's inside.

</comment><comment><USER28> A difficult article to write - I would not have tried. There are so many good alternatives and choice depends on the application and available skill sets.

I spent time today working in Clojurescript which wraps the Closure library. In the last month I have used Ember.js, Clojure with hiccup, and meteor.js. I really like all of these tools and frameworks. I used to use GWT a lot, and almost committed to Dart. So many good choices.

</comment><comment><USER29> Bad abstractions are dangerous. Good abstractions are empowering.

 _cough_ React Native _cough_

</comment><comment><USER30> I was slightly disappointed that this didn't point to a 404.

</comment><comment><USER31> This article reminds me quite a bit about Vuejs. Its got an interface similar to Backbone but with the addition of two way data binding while also allowing you to define web components style tags, attributes.

</comment><comment><USER32> I like the structure of google closure, thoughts?

</comment><comment><USER33> Vue.js meets most if not all the criteria outlined in this article. I've been have great luck with vue.js after a nightmare of fighting with writing a big SPA in Angular.

</comment><comment><USER34> The perfect JS framework won't exist until 2079.

</comment><comment><USER35> I LOVE ExtJS!</comment>


The history behind the decision to move Python to GitHub - <AUTHOR> http://www.snarky.ca/the-history-behind-the-decision-to-move-python-to-github <comment><USER2> > But to me, the development process is more important than worrying whether a > cloud-based service publishes its source code

And that's basically it (and I agree with him)

Do you have a problem with Github? All the information you need is in your clone of the Git repository.

(Ok, there are bug reports, wiki entries, but apparently those can be obtained using their API as well)

<comment><USER3> I'm not a Python developer, so I'm only a bystander here, but Python is moving from Mercurial and uses a patch-based workflow. Getting your changes into a project that relies on patches is trivial; you just send them the patch. GitHub doesn't support patches, however. The only way to get your changes integrated upstream through GitHub is to file GitHub's version of a pull request. And the only way to file a GitHub-style pull request is if it's coming from another repo on GitHub.

Cannon writes:

> GitHub is not a walled garden [...] GitHub is going to be used for > repository hosting and code reviews

The clincher is in the latter statement. Even though you may have the full repo history on your own disk, that doesn't do anything to help you get your changes back to the maintainers. In that case, GitHub _is_ a walled garden in the same way that people talk about Facebook being one. That is, it's fine and all if, say, your friend chooses to use it, but it makes some heavy-handed choices about how you can communicate/collaborate with them; it puts up barriers–deliberately–to make it onerous/impossible to use unless you're using it, too.

GitHub gets by on providing some free services to those working in open source and getting their goodwill in return. But GitHub's wall-y nature doesn't get called out enough, and indeed, people often act like it doesn't exist.

<comment><USER2> > The only way to get your changes integrated upstream through GitHub is to > file GitHub's version of a pull request

No

The Linux Kernel is on Github and only takes patches, not pull requests

<comment><USER4> Correct, but no part of the Linux kernel development is done on GitHub. It's nothing more than a republishing of the patch-based authoritative repository hosed somewhere else. The issue is that if you want GH to be your authoritative repository you're locked into GH's way of doing things -- which isn't necessarily bad, but a valid complaint is that you have to be a user of GH to contribute to projects hosted there.

<comment><USER2> > The issue is that if you want GH to be your authoritative repository you're > locked into GH's way of doing things

You just push from your (private) authoritative repository to Github, and you're free from "GH's way of doing things"

</comment></comment></comment></comment></comment><comment><USER5> I feel whatever be the reason it was a wrong move to move Python to github which is new sourceforge just more shiny. I hope the Python community get together to support either kallithea or trac or gnu and move there.

In an open letter recently group of open source developers raised and highlighted pitfalls of using such closed source for profit infrastructure without community oversight. Also it shows the opaque nature of such services. It's not wise to rely on goodwill of investors of github looking for profits. Also from ethical point of view it's really bad moving to a non community for profit infrastructure for a community driven project.

This is same mistake like moving from Python 2 to 3.

<comment><USER6> Try reading the article next time.

<comment><USER5> I read the article and the main reason for moving is wish of Guido and some developers personally. I was following the pep for Kallithea and hoped it will be picked up given Python is using mercurial which is already distributed and at par with git in features and workflow.

Also GitHub is another sourceforge, when Python did not move to sourceforge when 80-90% of developers were using it. I don't see why they want to move to GitHub just for source code management now when roundup will still be self hosted by Python. This is one of the reason I like gnu and gpl they not just build open source but continue to uphold the principals.

<comment><USER7> Not just on par, for those of us who want reliable cross platform behavior and gui tools (TortoiseHg), git seems lacking compared to mercurial.

Github is pretty shiny and popular though :|

</comment></comment></comment></comment><comment><USER8> > there was no killer feature that GitLab had

This really is the crux of the argument and for the GitLab guys is really what they should think hard about.</comment>


The American Way of Tech, and Why Europe Trails - <AUTHOR> http://mobile.nytimes.com/2015/06/19/business/the-american-way-of-tech-and-europes.html

<comment><USER2> No.

The real reason Europe/Asia/Latin America/Africa trails the US in tech is because none of these regions have even the same order of magnitude of funding, period. 2014: 225 deals in the UK for a total of GBP 1.7 billion (2.7 USD) so approx USD 12m/deal [1]. Same year: USD 48.3 billion in the US in 4,356 deals for approx 11m/deal [2]. That's 18x as much money. 18. Same deal size.

There's plenty of excellent programmers all over Europe, particularly (based on open source experience, and previous hiring) in the UK, Germany and Scandinavia. They're cheap, willing to do startups, capable of moving without a visa all over the region. Regulation is honestly not that bad; a bit more taxes, sure, but probably easier overall than California.

But if you have 18 times as many competitors, you're going to take more medals.

[1] [https://www.cbinsights.com/blog/united-kingdom-venture- capit...](https://www.cbinsights.com/blog/united-kingdom-venture- capital-2014/)

[2] [http://nvca.org/pressreleases/annual-venture-capital- investm...](http://nvca.org/pressreleases/annual-venture-capital-investment- tops-48-billion-2014-reaching-highest-level-decade-according-moneytree- report/)

<comment><USER3> Why does the US have more funding? Investors will invest where they can get the best return, there is no bias to country lines.

<comment><USER2> In theory yes. In practice, investments, particularly in early stage companies, require effort and time and other invisible costs (you can line up 20 meetings in San Francisco in the time it would take you to fly to Singapore and back for one), and there are other aspects such as reflexivity and the correlation between funding availability and company success that keep Silicon Valley as the global tech centre.

Why it became so is a long story with several aspects including large amounts of government spending half a century ago and cheap property values.

</comment></comment></comment><comment><USER3> "antitrust fervor in Europe seems to have hit fever pitch. Apple, Google and Facebook are all subjects of investigation, and Amazon is now the focus of at least three separate inquiries."

It's no wonder why Europe is trailing so far behind in technology and innovation.

<comment><USER4> Each of these companies direly needs investigation.

The alternative is to let each of them get away with anti-competitive practices and privacy violations.

The US tech industry is obviously leagues ahead of anywhere else in the world but it has brought some seriously shady anti-consumer goings on with it.

In a toss up between adequate consumer protection and a heavily pro-corporate economy I'd side with the consumer every time and take the industry hit.

Fortunately it's not a zero-sum game but the US is frighteningly lax on consumer protections in my view and it's festishisation of everything 'business' just leads to worsening standards for everybody.

A lot of this has been brought up as a point of debate in the Eurpean TTIP opposition, specifically the US trying to push it's much lower standards on Europe to the detriment of the average citizen and the benefit of big business.

<comment><USER3> What about Google, Apple, Facebook and Amazon 'direly' needs investigation?(Genuinely curious) What can the government do to aid said problems?

<comment><USER4> Exactly what I said.

Just a couple of examples I can remember from recent news;

Facebook's facial recognition, data policy and tracking of all visitors whether they have a profile or not is against EU law, so they are being taken to court. This is a good thing in my opinion. We have slightly better privacy and data protection rules in the EU countries and rather than weaken them they need to be strengthened and enforced to protect citizens. The EU reponse has been to draft new data protection rules which are being debated currently.

Microsoft was slapped with a heavy antitrust lawsuit years back and ended up paying a significant fine. This was the correct decision. Google are going through something similar at the moment although I am unsure of whether they should be found guilty or not. The point is, it's good that they are asking the antitrust question the first place.

You can find a lot of examples of the conflict between EU data law and industry competition standards and these few particular massive technology companies.

The question people would ask is whether the EU's laws on these matters are needlessly restrictive to businesses that operate in this industry.

Perhaps parts of it are but I wouldn't say so myself. If anything they need to be made stronger. There's far too much emphasis on the corporation over the citizen already and we need to start going in the other direction (highlighted by the large opposition to TTIP).

The downside might be that the EU countries never have a tech sector as great as the US but man, in the end it's worth it to protect the people from anti- consumer behaviour.

<comment><USER3> >The downside might be that the EU countries never have a tech sector as great as the US but man, in the end it's worth it to protect the people from anti- consumer behaviour.

Thanks, and I can see your point. Except for this last part, I'm having a hard time understanding the rationale. Do you mind talking more about how more government intervention and regulation could benefit consumers, compared to the current situation. How will 'the people' be protected? How will the government make better decisions than they can make for themselves? I don't understand how a smaller technology sector correlates to less 'anti-consumer' behaviour by companies?</comment></comment></comment></comment></comment>


Do you know who has shared your link on Twitter? - <AUTHOR> http://overviewmarketingsolutions.com/who-has-shared-your-link-on-twitter/

<comment><AUTHOR> I thought this would be something that everyone wanted to know. how many tweet have your link been in? I wanted to know this and i thought it has to be away to find out. So i found a way how to to do this on twitter . I was so surprise to how many people there actually were tweeting my link that i never know. The tool even tells you how many times those links have been clicked in twitter.</comment>