Hacker News new | past | comments | ask | show | jobs | submit | more seanstickle's comments login


I don't think a mega-compilation of the Western Canon is what OP is looking for...


Eh, they certainly tend to avoid fluff, and by definition, until you get to Marx, James, Freud you're not going to find "pop psychology"! A lot of them are very much worth reading, I personally would recommend:

Homer and a few Greek plays

Sample a bit of the great story teller Herodotus, then read the birth of historiography in Thucydides' History of the Peloponnesian War, which by itself is also very interesting and important (wonder why the Founder of the US didn't like direct democracy? There are very important object lessons in it).

Surely Plato and Aristotle deserve some attention! The contents of the latter's Rhetoric is essential for when you can't reach people with dialectic.

Euclid's Elements is still about as good as you can get for what it teaches.

Plutarch is great, but I really like that period of history. To it I would add reading some of the earlier bits of Livy.

Read, or better yet listen to audio of a few of Geoffrey Chaucer's Canterbury Tales, out loud you can follow their Middle English.

Machiavelli's The Prince is still damned good, and a landmark in talking about politics as it is, not as how people would like it to be.

Shakespeare surely needs some attention by English speakers. Swift's Gulliver's Travels were amusing when I read them in their original, and obviously very influential.

So, yeah, check out some of the classics.


One of my favorite books is "Algebraic Models For Accounting Systems" -- http://www.amazon.com/Algebraic-Models-For-Accounting-System...

Fundamentally this book is about the application of abstract algebra to the analysis of accounting systems.

Add in APL or J (or Haskell if you must) by way of "Algebra: An Algorithmic Treatment" (http://www.amazon.com/Algebra-algorithmic-treatment-Kenneth-...), and you build a quite rigorous proof-based accounting system.


Thanks for the recommendation. If it wasn't $73 I'd definitely grab a copy. Why is Haskell "if you must" though? Are the others better at expressing code algebraically?


Mostly because I'm an APL snob. Haskell is great.


We believe our test suite to be a complete test of the core accounting that we implement.

Would be beautiful to have a provably correct implementation, perhaps v4!


At least in my communications department, we follow a style guide — like Bloomberg's — and capitalize for our own purposes, rather than to further the marketing of another company.

E.g., "iPad, iPod, iTunes. Follow the company style for capitalization in text: iPad, iPod, iTunes. In headlines, capitalize because the words are nouns: IPad, IPod, ITunes."

Winkler, Matthew (2011-10-14). The Bloomberg Way: A Guide for Reporters and Editors (p. 304). Wiley. Kindle Edition.

And: "When a name begins with a lowercase letter, capitalize the first letter in all references: EBay, not eBay; EasyJet, not easyJet."

Winkler, Matthew (2011-10-14). The Bloomberg Way: A Guide for Reporters and Editors (p. 271). Wiley. Kindle Edition.


As far as I can tell, The Bloomberg Way is the only major guide that encourages that, and Bloomberg's own editorial standards are inconsistent such that they only use it half of the time: https://www.google.com/search?q=site:bloomberg.com+iphone


A quick search on www.bloomberg.com shows inconsistent application of the style guide. iPhone is universally styled as "iPhone", while both EBay/eBay and iTunes/ITunes appeared in headlines.


This is how I learned proofs:

http://i.imgur.com/omXqvos.png

Well, technically I learned proofs from Euclid first. But this book followed close behind.

Clear and comprehensible (once you learn the basic symbols). Very much structured. There's hardly any prose in the whole two volumes.


Care to share the title?



Ah, Russell. I've always been put off by people complaining about his somewhat pedantic approach. I guess I'll give it a try. Thank you.


Once again, I have to point to the Results-Only Work Environment — http://gorowe.com/pages/rowe-standards. ROWE isn't the only way of doing this sort of thing, but it's a good approach.

Companies hire people to produce results, not to sit in an office for a certain number of hours. Given this, stop trying to manage where and when people work, and start focusing on whether they are delivering results.

This endless parade of articles about work hours is reminiscent of people discussing the threadcount of the Emperor's clothes.


Forgive me if I am missing something that is obvious about ROWE, but what is to stop management from shifting the goalposts in a ROWE ? By continuously requiring more from their workforce they are receiving more hours of work from them while being able to say "We do not force set hours, we only require reasonable results from our employees" ?

It simply seems easy to manipulate.


That's a great question, tanderson92.

Unless you've had a remarkable work experience, you'll find that bad management shifts the goalposts in a 40-hour work environment too. "Work harder, work faster, work smarter!" This behavior is independent of the environment. The advantage of ROWE is that it removes a lot off waste (hours tracking, telecommuting paperwork, microaggressions about hours worked, etc.) and lets people actually focus on the work.

If you have executives that want to destroy the company by crushing the workforce then, yeah, no environment will stop them.


So what's preventing management from imposing huge amounts of workload when there's no limit to how many hours you work? The usefulness of a set limit of hours is that it protects the employee from work overload.


That's a reasonable concern, adeptus.

What's preventing management from imposing huge amounts of workload and telling you to get it done in 40 hours — or you're fired and they'll find someone else to do it?

I do not mean this at all flippantly. I've worked places (and I'm sure others have as well) where the amount of work assigned is undoable in the amount of time available. People burn out, people deliver poor quality, people quit.

A ROWE is not meant as a mechanism to protect employees from destructive bosses. And, for knowledge workers whose work cannot be mechanically reduced to hours, neither is a 40-hour week.

A ROWE is about removing waste in the work process so that people can focus on the work they're hired to do, not on outdated ritualistic traditions about work that no longer apply.


> What's preventing management from imposing huge amounts of workload and telling you to get it done in 40 hours — or you're fired and they'll find someone else to do it?

The thing is, under such a system, you get fired and that's the end of it, and the employer suffers for it as well as you. They can't push people to spend more than their 40 hours - they have to find somebody else who's willing to put up with it for 40 hours a week, or explicitly require more.

In the ROWE system, employers can collectively gradually push their employees to work more and more. 10 years down the line, everyone could have 50 or 60 hours worth of work to do a week, and no recourse, because every employer has gradually done the same thing - after all, if they can get more work out of you, they will.


A lack of recourse would only be the case if, as you say, 'every employer has gradually done the same thing'.

In an ideal world, all employees are able to be mobile, and would gravitate quickly away from bad employers, incentivising employers to not be bad (basically), and/or removing those employers / organisations from the environment.

I respect we don't live in an ideal world, but equally we don't live in a 100% evil - but somewhere in between the two extremes. So in practice you would see the same things that happen now - employers that aren't evil are able to obtain and retain better employees, in part because they don't engage in the kinds of activities you're describing.


I agree, and actually in a lot of countries you couldn't just get fired. Your employer would have to prove you really are slacking off, which would be hard if they're giving you more than 40h worth of work per week.


They'll think they do, but they won't really. Research is showing clearly that 60 hours a week is not sustainable longer than a couple months. Afterwards, you get less efficient than if you only worked 40 hours. http://www.salon.com/2012/03/14/bring_back_the_40_hour_work_...


I'm sure you don't mean it this way, but you should know that culturally, using people's names when replying to them the way you're doing often comes across as condescending.


The employee could quit and go work somewhere better. A manager knows the value of employees, if the place where I'm working now starts to shift the goalpost, then I'll walk and they'll lose whatever value I provided. It would take long for a manager to end up with an office of incompetent people because all the good ones would have left. Why do you think Google provides all those perks? Because they have to compete for labor just like everyone else. We aren't slaves despite some popular opinion suggesting it.


Hours tracking is hard to get out from under. In Canada, for example, tech companies get an annual tax rebate for R&D-related expenditures, under the government SR&ED program. One of the requirements for making the claim on any personnel expenses is signed timesheets.


Revenue Canada says [0]:

Individual time sheets that allocate time to SR&ED and non-SR&ED work are a good source of supporting information. Time sheets can be used to show the reasonableness of an SR&ED labour claim. Time sheet codes may be based on business projects that do not align to SR&ED projects. In such cases, other evidence may be required to support the SR&ED labour allocation.

So there are alternative means of proving SR&ED labour allocation.

[0] http://www.cra-arc.gc.ca/txcrdt/sred-rsde/clmng/slrywgs-eng....


I think there still needs to be a cap, probably around the 35-40 hour mark. Likewise, eliminating PTO generally seems to be a bad idea that can be abused by managers to keep their employees from actually taking PTO. I agree that leaving these issues to be implicitly resolved between employers and employees is a recipe that invites abuse, but if maximum work hours and minimum PTO are specified, ROWE is a pretty good policy.


Do Scrum. This way employees do their own time estimate and commitment to deliver. Replace them when burned out.


I probably agree (I have to read up on ROWE).

One thing is that "work week" mean different things in different contexts. One point of reference are full-time employees, that are paid a certain yearly salary. They typically work around 11 months a year (give or take a week or two), and are paid once every 12 months (with various takes on how vacation is paid for). The hourly wage is only a number used when calculating compensation for extra hours/overtime etc -- and compensation is based on more or less doing the same, every day, all year.

So what happens when people cannot, or don't want to work "full time"? In retail, "results" typically would mean you're at your post, servicing customers. In engineering, it doesn't really matter as long as the milestones are met.

You might need a reasonable yardstick against which to measure performance, if you want people to be able to adjust how much and when they work. I don't think there is a "one-size-fits-all" solution (well, beyond: "From each according to his ability, to each according to his need" -- which I think is a fine idea, but it demands some restructuring. Not perhaps only feasible under communism, one might view the idea of Japanese "employee-for-life" as another realization of the same idea).

All that said, counting hours, for most jobs (ie: those that aren't on the way to be automated away, anyway), is probably the worst possible measure of productivity -- and if one thinks compensation should be tied to productivity -- it is probably the worst possible basis on which to base compensation.

The benefit of measuring hours, lies in the simplicity. If people only work when at work, if they mostly work when at work, then hours at work should correlate with values produced, for that worker. You'd still need to price those hours (8 hours of amateur work, vs 1 hour of someone that's good at their job -- could readily be of the same value).


I'd kind of agree/disagree-ish. As I've commented on another HN thread about this, YMMV, but I've made peace with the fact they're paying for 37 hours access a week to my brain as much as the specific outputs I produce. I don't sit with people with my skillset, so I can help others (what's often referred to here as "interruptions"). Regardless of how much productive time I get out of that (c. 25, maybe), I'm there for questions to be asked of me, and to help others - and that's as much of my role as rolling out code.


How would that apply to the woman in the article, Ahlem Saifi? She works at the airport and at a market. A Results-Only Work Environment might work for some knowledge workers, but I don't think it would apply to the majority of the workforce.


See my reply to prostoalex at https://news.ycombinator.com/item?id=8679172


How would this work in restaurant business, hospitality industry or retail environment?


The same it applies anywhere. You want results from people in the restaurant business, hospitality industry, or retail environments, right?

A Results-Only Work Environment isn't a Remote-Only Work Environment. You work where and when you want, as long as your work gets done. If you need to be in the restaurant during certain hours to achieve your results, then that's where you are.

The focus is first and foremost on the results, and everything follows from that.


So a Results-Only Work Environment works because it focuses on results. Got it. That may work fine for programmers, but when knowledge worker theory meets the reality of a mass workforce, you're resorting to a circular argument. The GP cited businesses that need employees available at all hours when the business is open. That's the only way to get results. So in the context of a 35 hours work week, I don't see it as applicable. Convenience stores, restaurants, and hospitality businesses would just end up hiring more part time workers.


I would encourage you to read the book "Maverick" which examines a lot of this in detail. It's interesting the environments they've applied these types of structures to. Including line-manufacturing.

http://en.wikipedia.org/wiki/Maverick_%28book%29


Disagree. It only really works for workers that are actively producing. For jobs that are reactionary (mainly service jobs where customers come to them and they are expected to deal with them) it doesn't really work. You need someone in the store or answering the phones during certain hours.


I favor something more like a Results-Only Work Environment (http://gorowe.com/pages/rowe-standards), where the focus is on the results and not on how many hours are worked.

Too many companies (even startups) are conservatives and traditionalists in the sense of thinking that work needs to be done within certain hours and at a certain place, even when those are not drivers of the results.

I'm hired to deliver certain results, not to work a number of hours. If it takes me 10 hours or 40 hours to deliver those results, that's up to me, as long as the deadlines are hit and the deliverables are high-quality. And there's no reason to be in an office, unless the office is instrumental to achieving those results.

The focus on how many hours people should work is a fetish that reinforces a still-dominant 20th century office culture.


I agree with you personally, but to play the devil's advocate a little:

>If it takes me 10 hours or 40 hours to deliver those results, that's up to me, as long as the deadlines are hit and the deliverables are high-quality.

If you are able to consistently deliver the required results in only 10 hours of "work", it's clear that any organization will slowly ramp up the required results more and more until you are working 40 hours a week.

How would you agree on results that are "enough for the company" that won't grow endlessly when they see you're only working 10 hours a week?


This is a cultural change that the company has to go through.

They're paying me for the results. Not for the hours.

Thinking that they'll "ramp up the required results more and more until you are working 40 hours a week" means that you're still thinking that you're paying for hours.

Still, it's the responsibility of all employees to improve the process that they work in, just as part of the company's continuous improvement. Which means that more/better results will be delivered over time anyways.

How do you agree on results that are "enough for the company" when you hire a consultant (assuming they're an intelligent consultant and don't charge by the hour).


The queues of things to do is always extremely long.

There are 1000 tickets in your JIRA queue. They then ask you, what can you do in the 2 week (or 1 week) sprint?

What do you say? Is it the 10 hour or 40 hour timeframe? That happens all the time in development, and people do a few things. They underestimate a lot or they write code that is 90%, where when bad things happen, it's ugly to clean up.

So the results are what you say you can do in your week of work. And of course, they will put the pressure of "but that's easy." Yada yada.

As a results oriented place, some companies pack in what you think is 80 in your 40 hour work week (a lot of companies will try to do this). So what happens then? You switch jobs?

As for improving the process, most engineers don't know exactly how. They speculate and guess, hoping to hit it right. It's really up to the people driving it to affect the company culture. Doing it as an individual within an organization is quite difficult.

That's what I've experienced at certain companies anyways, generally with management with less experience, tbh.


Let's be honest. Both a Results-Only Work Environment or a "9-5 in the office" environment try to pack as much into an employee's schedule as possible. That's not unique to ROWE.

Some of the answers to your questions are: well, what do you do now, and how can that be made better? ROWE isn't magic. It's just a recognition that pretending that you're paying for hours spent in an office is nonsense, and that we should talk about the work itself rather than the things that don't have to do with the work.

The old equation (fetishistically held to, even in the face of its absurdity) of TIME + PRESENCE = RESULTS typically takes the focus of the conversation, and we end up in conversations about who can work remotely, and how many hours people should put in, etc. Instead of talking about the stuff we're actually paid to deliver.

As for not knowing how to improve processes, I don't mean that we should just say to them "hey, go improve things." It's a crucial management responsibility to make sure that people know how to do this sort of thing, to teach them how, and to provide ongoing coaching in doing it.


> They're paying me for the results. Not for the hours.

True. But since "results" aren't exactly quantifiable, how can they get steady value for their money?

Is result A equal to result B or result Q? If results M, N, and O are all equal, how many M/N/O results does it take to earn one week's worth of paycheck?

What if they decide that they're paying too much for M/N/O results, and want at least 11 of those per week instead of the current 4?

What if you wait an entire week for the dumb assholes in the other department to deliver the specifications? Do you not get paid that week?

You're paid by the hour not because hours are the best way to measure accomplishments, but because it's easy to measure hours and difficult to measure anything else.


I feel for you. Apparently you don't have a boss who can define what they want from you. This is not uncommon, and we're struggling with that ourselves. We've all spent so many years with the belief that putting in hours is the work, that we don't really know what we've hired people to actually do.

All your questions are the same questions you have in an TIME + PRESENCE = RESULTS job. What if they decide they want 11 instead of the current 4. What if you wait an entire week for the other department? These are all still problems. Are you excusing yourself from dealing with them because you say "hey, 40 hours in and I'm done, bye!"?

It's not difficult to measure results of work that you hire people to do. It's hard to decide to start doing that though.


I'm all for the 'results based' work environment but I think measuring results of work that you hire people to do IS quite hard.

A great example is refactoring. Say you hired a dev and he delivered a product that worked but is written terribly (already a question there, how do you gauge that in terms of 'results'?). Now you hire a second dev to clean it up and make it maintainable. How do you evaluate when he has delivered the 'results'?

edit: I think the closest thing to a true results based workplace would be an early stage startup. Everyone is invested in the product and striving towards creating it, not just putting in hours. In those cases people usually end up working WAY more than 40 hours a week.


> A great example is refactoring. Say you hired a dev and he delivered a product that worked but is written terribly (already a question there, how do you gauge that in terms of 'results'?). Now you hire a second dev to clean it up and make it maintainable. How do you evaluate when he has delivered the 'results'?

Easy. Lines of code.

The first developer did an awesome jobs, many lines of code were written. The second one is a lousy hack, he earned about $50 (not $50k).

This is ridiculous of course, but it does show how even bad measurements are preferred over non-measurement.


this sort of give/learn/take averaged over multiple employees could redefine how much can be done in a week, or what the average rate per hour is, but in the end the time would be spent more efficiently. I believe that having a set number of hours will grow the workload to meet those hours, and that's inefficient in most cases. No studies to back this up, but I've worked in a lot of places, and the percentage of people that are actually trying to get done as much as they can [in a working day] is very low.


Forcing someone to punch a clock is definitely misguided. But work hours are a useful proxy for effort spent, provided you have good estimation of your pace. And being in the office not only puts you in a “work” frame of mind, but also promotes serendipitous sharing with your coworkers—swapping productivity tips, planning features, explaining systems.

So even in a quite results-oriented workplace, with almost total freedom over my hours, I still often choose to go into the office for about six hours a day.


Work hours are certainly a good proxy for effort spent. But companies don't (or shouldn't) pay for effort, they pay for results.

Take 2 people: one a talented auto mechanic, one is me (not mechanically talented). Give us both the task of changing all 4 tires on a car.

I take 8 hours. The mechanic takes 1. (Made up numbers, but you get the idea).

8 hours reflect my effort, sure. But you want the tires changed. If the mechanic finishes in 1 hour, great. That's what you're paying for — changed tires. Not hours.


Sure, but I would be equally happy to pay either of you by the hour if you set your rates according to your respective skill levels, because the price would come out the same. Also there is an implicit expectation of reasonable competence.

For example, hourly pay is quite reasonable in jobs that just need a competent body to fill a shift—i.e., where the only “result” you want is “the shift gets filled”. When I was working in a kitchen, I put in the same four-hour shift every time I went into work—prep, serve, clean. If I worked n shifts a week, I got kn dollars that week, fair and square.


I would also point out Richard D. Wolff's arguments about forming cooperatives instead of corporations.


Calling people "independent contractors" doesn't necessarily make it true. Depending on jurisdiction, they have to meet certain criteria to be called that; otherwise they're an employee, and the company can be subject to penalties from the IRS and Department of Labor (in the US).


What I find disturbing about this is that lean concepts, from Deming to Toyota to software dev and so forth, is meant to benefit both the company and the customer — reduce waste, increase flow, make products and services that people want and that make companies money.

"Lean recruitment" is a bastardization of the term, as it's basically a cool-sounding way for companies to exploit job-seekers in a way that doesn't make things better for the job seeker but certainly advantages the company.

Company gets some free (which may be illegal in some jurisdictions) or paid-but-still-illegal (just saying "independent contractor" isn't a magic word) labor and a low-cost way to vet candidates. Job-seekers get ... an opportunity to work in a diminished capacity in the hopes of getting a job. And no, calling someone an "independent contractor" doesn't necessarily make it so, if the person is doing work in the office, under your direction, with your equipment — companies get in trouble calling people independent contractors when they're actually employees. The description from the original post certainly sounds like it fits this pretty well.

I don't think the current interview process is working as well as it could, and it's ripe for some rebooting. But I don't see that labelling "worker exploitation" as "lean" gets us there.


So, what do you suggest? What is necessary to improve the recruitment process?

PS: Automattic, the company behind WordPress.com, use tryouts to test candidates, you can se more at http://hbr.org/2014/04/the-ceo-of-automattic-on-holding-audi...


When Hercules cleaned out the Augean stables, he wasn't then obligated to refill them. Just because I can see a problem and criticize a fumbling attempt at a solution, it does not follow that I have an alternative.


Also, depending on local and regional laws, asking people to work for free can be illegal.


This is my difficulty with J as well.

APL has a better mental "feeling" for me, more like mathematical symbols. Oftentimes, these are pretty direct.

Want to drop the first element of a vector?

APL: 1 ↓ 1 2 3 4 5

J: 1 }. 1 2 3 4 5

The APL version looks like a drop to me. The J version looks like two characters that I have to remember the meaning of.

I'm sure if I was deeply proficient at J, the two-characters would stand out by their meaning, but it's hard for me to get that far when APL is so much cleaner for me to read.


The APL version looks like addition (cons, prepending value to a list) to me. The point being that you have to learn the meaning of symbols anyway, no matter which character set they use. Going for easier input (from the keyboard) and sacrificing a bit of legibility for this is a perfectly fine design trade off to me.


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: