Conventional Comments - <AUTHOR> https://conventionalcomments.org/ <comment><USER2> It seems I disagree w/ many points.

        > - Leave actionable comments
        > suggestion: This is not worded correctly.
        > Can we change this to match the wording of the marketing page?

If I already know how it should be, I prefer to quote it right away and save work, instead of asking and leaving room for misinterpretation. Asking also seems dishonest if I'm not truly inviting a discussion. I would still add a rationale so others can correct me though ("Changing this to match the wording on the marketing page").

        > - Combine similar comments

Sometimes it's better to be repetitive in the name of exactness, because most review tools are line-oriented. Otherwise I have to write a comment "See lines A, B, C, D, E", and the person asking for the review now has more work to do searching all the instances.

        > - Replace "you" with "we"

Better yet, I replace all pronouns w/ "this". Criticise the work, don't make it personal if it's not necessary. "We" feels forced team-building, and dishonest if I'm not actually going to put in work.

It seems these practices are created because people are using reviews as some form of conversation, and then everybody is stepping on egg shells. I believe if the entire team agrees to see it as just annotations (it's not a performance evaluation, leave your ego at the door, etc) these problems are avoided.

(I can see "why" you need these guidelines though, I guess it depends on what kind of work culture you have, company size, and so on.)

<comment><USER3> It's very easy to seem rude in text comments, even if it was not meant that way at all.

"Change 'this' to 'that'" is much harsher than "Could you change 'this' to 'that'?"

It's a small change in wording, but it changes the interpretation from "This is wrong, do this instead, I know better than you" to "I think this is a better way to do it".

<comment><USER2> Is it really?

I can find instructions disguised as questions condescending, for example.

I believe no amount of wording will help if people are not trusting each other. I would rather work on team building than comment guidelines.

<comment><USER4> But instructions are given by superiors, while code reviews (generally) by peers. If someone you don't respect starts barking "Change 'this' to 'that'", would you?

I mean sure, in some cases you can completely disassociate from the human side of code, disregard a comment's name in favor of objective truth or however you want to word it, but in a lot of instances you still have to share the same office with that person.

</comment></comment></comment></comment><comment><AUTHOR> Very much inspired from Conventional Commits, this expands the idea to review comments.

At GitLab, we are a fully remote organization so we do _a lot_ of written communication. This has been a great pattern for improving readability and the content of review comments. Plus, it's machine parseable which means we could easily query and aggregate these comments in the future!

</comment><comment><USER5> I agree with the vast majority of this, but I have a bad reaction to "praise" and the idea that you should try to have one per review. I hate praise that feels forced, and it seems like this kind of practice would make it seem quite forced.

I feel you could just say something like "good idea" and it would be fine without the prefix. Especially if your review tool of choice has a concept of actionable vs non-actionable comments, like Gerrit and resolved/unresolved comments.

<comment><AUTHOR> > I hate praise that feels forced, and it seems like this kind of practice > would make it seem quite forced.

This is a _really_ good point.

Yeah, the `praise` comment is a call to find something to _sincerely_ praise. If you can't find anything to praise (which is probably a warning sign that your head isn't in a happy place) don't leave a `praise`.

I updated the description with a little warning about this. What do you think? [https://gitlab.com/conventionalcomments/conventionalcomments...](https://gitlab.com/conventionalcomments/conventionalcomments.gitlab.io/-/merge_requests/12)

</comment></comment><comment><USER6> I get the ones where you're suggesting alterations to the code, but having "praise: You did great here" or "chore: Could you run the tests" sounds weirdly robotic to me

<comment><USER7> It reminds me of the Elcor from Mass Effect. The problem they face is similar to textual comments: Elcor cannot emote in a way that's detectable to non- Elcor, so when communicating with alien races such as humans, they have to prefix every utterance with an emotional descriptor. E.g., "Pleased greeting: Human, it is always good to see your kind."

<comment><USER8> Oddly, this has made me want to try Mass Effect.

</comment></comment></comment><comment> munk-a When leaving review comments our internal system is to use a blocking/non- blocking flag along with the classic three RFC keywords (MAY/SHOULD/MUST - often in bold) as two examples:

You MAY wish to improve readability here by binding these values to a local variable

We're using string building in this query with user input we MUST not allow any SQL injection routes.

<comment><USER9> Uh I like the idea of RFC keywords. For reference the RFC2119 which defines them:

[https://tools.ietf.org/html/rfc2119](https://tools.ietf.org/html/rfc2119)

<comment> munk-a Feel free to steal it - we've found it works pretty well!

</comment></comment></comment><comment><USER10> This sounds great! I have often felt the lack of a common language to specify for each review comment if an action is expected. This looks like this convention solves the problem with a nice Schelling point.

nitpick (non-blocking): I won't use the "praise:" keyword as it feels robotic. Praise should feel spontaneous and authentic. But I love the general advice of trying to have at least one praise comment per code review.

</comment><comment><USER11> Nerds get a big rush from creating rule systems. And doubly so if then able to foist them on others!

<comment><USER12> Yah, I have to say material like this getting any attention really accentuates the feeling I get that we're scraping the bottom of the barrel for how to improve in software. It seems like we're more and more focused on the (relatively) superficial...language ergonomics, conventions, etc

</comment></comment><comment><USER13> I'm guessing this is about Code Review comments?

I _always_ assume my comments on others' PRs (and other people's comments on my Code Reviews) are "suggestions (non-blocking)", _unless indicated otherwise_. Shouldn't that be the default, really?

<comment><USER14> If you use gitlab for code reviews, it's actually the opposite. Each comment thread prevents a merge unless you hit the "Resolve thread" button. It's configurable, but AFAIR it's Gitlab's default.

Even though I also often use Github and Gerrit at my current job, everywhere we observe that convention that a comment is considered blocking unless indicated otherwise. This is because ~80% are typically blocking.

<comment><USER13> Interesting, so "passive-agressive" is already built-in. Meaning even commenting in a very innocuous style "I'm not sure if this is correct according to the style guide..." would prevent a merge.

I personally try to encourage _both_ communication _and_ responsibility. So I comment on pretty much _everything_ I don't understand/like/agree with (i.e. over-communication, that's really the only way to ensure adequate communication because by over-communicating according to _your_ standards you're more likely hitting the _other person 's_ communication standards, which are necessarily different from your own and fundamentally unknowable), but at the same time I encourage the other person to decide which comments they want to respond to (either by arguing or by changing the code), hence showing I trust them and encouraging their personal responsibility.

<comment><USER15> I think "passive-aggressive" is a bit too strong. If you leave a comment, even if not blocking, resolving that discussing can simply be a signal that the author of the MR has acknowledged it.

The proposal of conventional comments simply clarifies intention and disambiguates it. It's like that salt and pepper question. How do you know which is in which? Regardless of your knowledge and assumptions, it depends on whoever filled them in. This clarifies that.

</comment></comment></comment></comment><comment><USER16> Why the 'we' if 'we' aren't going to do it, but _I_ am?

I've had one interesting/productive 6 month engagement with a team where there were some of these comments, but _sometimes_... someone would actually just make the change in the branch. It saved time, let them get things "the way they wanted" and was generally agreeable to most on the team.

Someone making a change in 'my' branch wasn't an affront - it was a degree of collaboration. It was almost always preceded with a message of "hey, I see a small issue here - I'm gonna throw a small patch on it - let me call you after to discuss" or followed up with "hey - fyi - I saw a small bug and did a small patch/test - do you have a few minutes to talk at 3 about it?"

And... I would do the same with them, when warranted. It cut down on the delays and let people "take ownership". In the 'wrong hands', I'm sure it could get politically ugly, but no more so than a lot of passive-aggressive comments and blocking/nitpick stuff that holds things up unnecessarily.

One thing that was expected (and made it easier) was that whenever you did that (formal or informal review) you were expected to have pulled the code, installed/run the tests locally, run the code, and verified tests ran before you pushed anything back. A note saying "this doesn't seem right" carries different weight from someone giving it a 2 minute glance vs someone who's actually _run_ that code and seen what you've seen. Yes, I know that often you can spot issues without running the code, but... not always (or, if you see the totality of the code in-situ, vs just diffs, you have more context).

</comment><comment><USER17> I appreciate the intention behind these things. However, I do not feel like this method is better than to just use the English language, if everyone is fluent in it.

For instance, `praise: nice test` sounds a little weirdly robotic in the way that if you were to walk up to someone and say "I am now going to give you a compliment. You are wearing a nice dress."

<comment><USER18> [I agree with you, with qualification]: sometimes we do need to disambiguate by announcing our mental state at the beginning of a comment!

</comment></comment><comment><USER19> Only tangentially relevant:

I hate the word 'nitpick' (bad experience with small insects - thinking about nits makes me itch), but I don't know any other word for these "small, trivial, but necessary changes." Does anyone have alternative words they use in reviews instead?

<comment><USER20> I'm also not a fan of this phrase, which is whipped out to be "helpful" in reviews at my current employer--probably after the last time this website or one similar to it bubbled up on HN.

To be clear, the (American) dictionary definition of nit-picking is "minute and usually unjustified criticism." In other words, this is definitely not a positive thing to do, which is why this word has such strong negative connotations. Who wants to be nitpicked?

Nit-picking is not a "necessary" change, which is what makes it an exercise in finding the tiniest of fungus flies lurking in a proposed change. "I don't really want to think too hard about what you're proposing, or what your pull request contains, so here's a nit I noticed while examining the bike shed in front of your nuclear plant. #didmyjobboss"

I don't know what a trivial but necessary change is, but that's certainly not a minute criticism.

<comment><USER18> Au contraire: if I give you ten "nitpicks", the fact that it's "minute criticism" means that you explicitly have licence not to feel bad about it. I use the word "nitpick" in a review to induce the reaction of "sigh, I'll make your tiny change", possibly with "I-the-author don't care but apparently you- the-reviewer do for some reason" and "it's all Smaug123's fault for being unreasonable" if the author needs someone to blame mentally for the fact that the PR isn't approved immediately. It's an explicit label/reassurance that no important fault lies with the author.

This is very possibly a team culture thing, though. We all know that the code is what matters, and we are all studiously not letting our egos intervene, but we can help each other not get too attached by deflecting the blame onto the reviewer rather than the author in this tiny way.

</comment></comment></comment><comment><USER21> I like these ideas a lot and if I was mentoring someone in leaving feedback I would strongly encourage providing examples along with suggestions. I like that the "suggestion" label provides a little mental prompt to do that. The easier it is to take action on feedback the better. A diff patch or PR would be ideal.

In the office environment where I find I'm often using MS Word with track changes to collaborate (horrors!) I'd much rather a reviewer make a tracked change and leave a comment in the document then send me an email.

The flip side is reducing friction for reviewers by making your document easily accessible, and easy to change and comment on, pays dividends.

</comment><comment><USER22> I've started doing something like this naturally. I felt the need to communicate it could be improved but the code per se is not wrong. I started using suggestion, optional, minor, etc. This seems like a formalization of what I had in mind, thanks

</comment><comment><USER23> This document is inspired by Conventional Commits but lacks the equivalent Specification section. The point of adding structure to unstructured text is specifying the syntax required to make it machine readable. Maybe I'm missing something.

<comment><USER15> I agree it's very light, but isn't this what you mean? [https://conventionalcomments.org/#format](https://conventionalcomments.org/#format)

</comment></comment><comment><USER24> On a previous engineering team, I once proposed a comment tagging convention that evolved over time to a stable place and ended up being quite useful for us. Unlike Conventional Comments, though, our main motivation was to communicate _expectations_ clearly, so the person receiving the review has enough information to decide what _action_ to take.

The Conventional Comments labels help a little, but requests for action are lumped under "suggestion" and "nitpick" and "chore", which I don't find to be useful distinctions. "Suggestion" doesn't tell me whether the reviewer is just offering an idea for improvement or pointing out something that must be addressed, and doesn't tell me whether I need to check back with the reviewer before merging my change. If I get a "question", then after I answer the question, is it okay to merge or not? "Issue" doesn't tell me if the issue is big enough to block the PR.

——

Here's our system:

• [help] means "I need help understanding this PR". I can't do a useful review of this PR without a better understanding. Please talk to me before proceeding.

• [fix] means "fix now". I've identified a problem; please fix it before merging. If you don't agree that this needs to be fixed, or you think we should do something different from my proposed action, please discuss it with me before merging -- we probably have a significant difference in understanding that is important to sort out.

• [fix?] means "fix now if bug". This looks like it might be a bug, but I'm not sure; please evaluate it, and if it's indeed a bug, treat it as a [fix].

• [minifix] means "fix now if small". I'm asking for this to be fixed before merging because I think it will take <30 seconds. If it takes longer, forget it.

• [postfix] means "postponable fix". This is important enough that it must be fixed, but it doesn't need to delay urgent work. You can decide if you want to do it before or after merging this PR.

• [cbb] means "optional, objective" ("could be better"). This could be better in the way I'm suggesting, but it's not so important that it must be fixed before merging. I'm making a recommendation as a good practice for next time.

• [taste] means "optional, subjective". I'm suggesting an improvement, and I'm acknowledging that it's a personal preference. I am not demanding that you change your preferences long-term, but I'm offering it because I find this practice useful and think you might find it useful too. If you like it, use it.

• [fyi] means "for your information". No action needed. This might be mentoring advice, or a reference to something else that's relevant, or a thing to note for the future, etc.

——

I like this system because each tag makes it very clear exactly what action is required before merging and under what conditions there needs to be further discussion with the reviewer.

[help], [fix], and [fix?] are blocking: the PR cannot be merged as-is without discussion. For [fix] the communication loop must be closed with the reviewer; for [fix?] the communication loop can be open.

[minifix], [postfix], [cbb], and [taste] are non-blocking: each one identifies _why_ the suggestion was made so the receiver can decide whether or not to take action. In practice, we found that these 4 categories did pretty well at covering the most common reasons behind suggested actions.

Notice: [fix] and [minifix] aren't about whether the change is big or small. A [fix] could be big or small; the important information is that it's mandatory. The smallness indicated by [minifix] is relevant only because the smallness is the _reason_ for the suggestion.

Notice: There's no [chore] or [style] or [nitpick] category. [style] doesn't help, because we still don't know whether the style change is mandatory or merely recommended. It doesn't matter what kind of thing we're asking for; what matters is what needs to be done about it.

<comment><USER25> [taste] It would be cool if this were a blog post or something so I could refer to it someplace more canonical than this post. I would like to try and use it in my own projects.

</comment></comment><comment><USER26> This is just a hack to the problem that most people can't write and don't know how to write something that's valuable to the reader.

Just put some thought and care into the comments.

<comment><USER27> > most people can't write and don't know how to write something that's > valuable to the reader

...yes? And?

99.999% of people's comparative advantage is not in their writing ability.

Add to this that learning to write to a quality level required for effective, efficient communication, is a far higher burden to place on someone, than the level of fluency required for basic exchange of information; especially for people for whom English (or whatever language is being used) is a second language.

Taken together, this implies that for most people, learning to write _well_ —i.e. learning the skill that, having possessed it, would make you into a competent essayist—would be a waste of time. Just like learning abstract mathematics would be a waste of time. (And I say that as a professional author!)

Most people intuitively know that learning to write more effectively isn't the best use of their time, and so most people don't try.

This "hack" is far less costly, and therefore far more likely to get adopted by these people, and therefore far more likely to actually improve the experience of _reading_ the average communication in a large software project (which tends to involve people of varying communication levels.)

<comment><USER28> I abhor the idea that learning to communicate effectively is "a waste of time." Rather than try to avoid learning an incredibly useful skill, people who CAN'T communicate effectively could use code review as a learning/skill building opportunity.

If I switch "communicate," with "program," do you still think it's a good argument that people shouldn't obtain any more programming skill than the most rudimentary level, because it would be a waste of time?

Conversely, I think clear communication will probably help you write better, clearer, more concise code.

It's a win-win.

<comment><USER27> > Do you still think it's a good argument that people shouldn't obtain any > more programming skill than the most rudimentary level, because it would be > a waste of time?

...if programming isn't their comparative advantage, then yes. A project manager, or a salesman, should not spend their time learning to code. It's not the most valuable thing they could be doing to increase their ability to do their own job.

> I think clear communication will probably help you write better, clearer, > more concise code.

You realize that communication occurs in a specific language, and the problem is often more to do with lack of knowledge of the language the communication is occurring in, right?

Someone might be extremely eloquent in e.g. Spanish, but that doesn't mean they're going to be able to communicate effectively in English. But that _also_ doesn't mean that they aren't going to be able to write good, clear, concise code. They already know how to communicate well; they already have the meta-skill that results in both good writing and good code. They just don't have the specific skill of arranging powerful, pithy words _of English_ to concisely represent a complex concept.

</comment></comment></comment></comment><comment><USER29> The blogpost needs an introduction: type of comment.

<comment><USER30> "Introduction" isn't really a tone or a descriptor that changes how you act on the information like the rest.

<comment><USER31> My feeling is that the blogpost needs some introduction, stating at least the context of the comments it talks about. Browsing through the comments here at seems about code review, but the blogpost itself never says that.

I think but I'm not sure that's what js8 meant too.

</comment></comment></comment><comment><USER32> Dream: Can we please get this on YouTube. User comments there are a disaster and they're making the entire platform worse.

Thank you for making this...and to the naysayers, suggestion: Do it better or stop blocking. This is miles better than doing nothing. And downvote, like always, if it makes you feel better...</comment>


Ask HN: What does it mean to be happy at work? - <AUTHOR>

I have a background that includes working at small businesses, my own startup and most recently, F500 companies. I feel like I'm always on a roller-coaster of highs and lows, things that I need to accept or risk getting into political trouble, and the inability to call out failures, when we run into them. So, I thought I'd ask you all how others feel at work and what's considered good / bad / normal.
What does it mean to be happy at work? Is it basically tuning out, punching a clock in exchange for a pay check? Is it doing everything possible or just meeting expectations? Are you truly vested in your work and the company's success? Or, do you just make sure you always have a lifeboat in case things go wrong?
Thanks, <comment><USER2> I think it boils down to one thing. How would you feel during your speech announcing that you're leaving?

I recently thought about how this speech would go for me, and I actually started getting a little emotional. There is such a strong feeling of community at my job (and this is after a mere 6 months of working there), and I've made some really strong friendships here.

One think I feel is important is that being happy at your job doesn't mean enjoying every second of it. I have to do stuff every day that makes me moan and groan. Supporting IE8 isn't fun times - but when you can manage at least 3 honest belly laughs a day at work, you've found a home.

<comment><AUTHOR> What an interesting thought. I feel like my speech would be an analysis of the things that I couldn't change, but think the company would need to figure out if it's goal is to be the kind of place that attracts people like me...or ideally a lot smarter than me.

Then, they'd probably agree and do nothing about it. Which is what led to the speech in the first place.

</comment></comment><comment><USER3> I find I go through ups and downs as well. My ups generally occur when I accomplish something, when I work on something meaningful, when I help others, when hard work gets acknowledged, when I learn something new, when I influence change, when a complaint or a concern doesn't go unnoticed, etc. The downs on the other hand are primarily connected with feeling of helplessness, often due to restrictive hierarchy and bureaucracy, staleness (same work every day), status quo, frustrations that go unaddressed, etc.

edit: tuning out, punching in/out (ass in a seat), meeting expectations for me are all signs that point to me being stuck at a job without much enjoyment. Not being vested in the company is a tricky one though - I am ready to make certain sacrifices for a company, however I will always ensure I have a backup strategy. The same should hold true for companies as well.

<comment><AUTHOR> That's almost verbatim where I am. The ups come with progress, little accomplishments or whatnot. But, every time I hit an arbitrary wall, it's a huge downer.

I'm just glad it's not just me.

</comment></comment><comment><USER4> When your work is what you want to be doing, where you want to be, and the people around you are the people you want to be around, you're happy at work.

<comment><AUTHOR> Unfortunately, I'm not even sure that's enough for me, b/c it's such a mixed bag. I love my work, but hate the bureaucracy when it works against me. I like the people I work with directly, but the org is big and wide...and I don't care for all of them.

</comment></comment><comment><USER5> Growth. Have you learned something new today? Are you around people who can teach you a thing or two? Are you pushing yourself? The best jobs change you. Make you better.

<comment><AUTHOR> I get to learn a lot. I play with new and cutting edge technology, applying it to solve current business problems. However, it's unclear to me whether or not what I'm learning is the environment isn't 100% conducive to me being happy.

Maybe it'll always ebb and flow. Or maybe I'm doing it wrong. That's why I asked the question.</comment></comment>


GAE: Latency spikes & aborted requests in the last 24 hours. Any options? - <AUTHOR> http://groups.google.com/group/google-appengine/browse_thread/thread/b849776947527dcb/95e3ded59c9a3506

<comment><AUTHOR> Google's discussion and categorization of the issue here:

[http://groups.google.com/group/google- appengine/browse_threa...](http://groups.google.com/group/google- appengine/browse_thread/thread/6ded39ad5166d0be#)</comment>


Leave Work Unassigned and See Who Steps Forward - <AUTHOR> https://www.mountaingoatsoftware.com/blog/leave-work-unassigned-and-see-who-steps-forward <comment><USER2> Ugg. I'm sorry about being negative but here are some protips:

1\. If a manager leaves work unassigned and you pick it up, prepare to have a LOT more work dumped on you in the future for no reward.

2\. If you pretend to be a manager with hopes of being made a manager, all that you will accomplish is you are going to end up doing your job AND your bosses job. Your boss will look like a hero to his/her peers. You'll kill yourself and won't be made a manager regardless.

A better approach is to be smart about it. Always negotiate the work and what you're going to get out of it ahead of time. Maybe you just get some political capital, praise, or a positive review. Don't just blindly do work you weren't asked to do thinking it will be rewarded.

<comment><USER3> If I may, here is some of my protips:

\- The best route up is hitching your wagon to your bosses wagon. So yes doing some of his work will make him look like a hero, which will get him promoted, and he'll think who is his most valuable / productive underling, which will get you promoted. Hopefully you doing some of his work free's up his time to be more productive in other areas. If your boss is a lazy PHB (Dilbert), get another job.

\- It is far more difficult to try and get promoted around your boss. Don't try this, it doesn't work.

\- Reward isn't always immediate. A previous manager of mine's advice was: You can't keep a good man down. Eventually someone will see the extra effort you put in and reward you for it, even if it is an ex colleage getting you hired at another company.

<comment><USER4> Maybe I've had more than my share of bad bosses, but I don't really agree with you here. I must say, also, that in my experience, it does depend on the company size, culture and abilities of said managers more often than not (big, hierarchical companies tend to be worse at this kind of thing, also, banking and financial, not sure why).

\- A good manager will notice, and appreciate, your effort. But promote you? You are one of his best tools, why should he? Usually he'll try everything he can to keep you where you are. If it's a bad manager, he won't even recognize your effort.

\- Yes, unless you work with mixed teams or on different projects. In that case, two managers might end up fighting to get you on their teams and it might be a good thing for you.

\- Nothing to say here, you are totally right, but depending on how you play your cards, the reward can come earlier. Only thing I'll point is that I've seen departments go to hell because managers failed to recognize this.

My tip would be to communicate. If you have free time, don't wait for your boss to assign you work and ask. If you see something else that you can be doing (sometimes there are features or bugs that could be worked together), say so, but always comunicate first and wait for your managers decision.

Of course, all this is IMHO and your results may vary.

<comment><USER5> _\- A good manager will notice, and appreciate, your effort. But promote you? You are one of his best tools, why should he? Usually he 'll try everything he can to keep you where you are. If it's a bad manager, he won't even recognize your effort._

Your parent comment:

 _make him look like a hero, which will get him promoted, and he 'll think who is his most valuable / productive underling, which will get you promoted_

So, your manager got promoted, so in order to keep you around, he'll try anything, including promoting you, to keep you as one of his best tools.

<comment><USER4> Again, maybe I've had more bad managers than the average (in my 17 years of professional experience I've had 2, maybe 3, good managers), but there's no guarantee that will happen.

Maybe in areas like SV, where good professionals with solid experience have no problem finding another role and companies are actually trying their best to keep good employees that happens more often. What I've seen is people skipped for promotion in favor of the manager's son friend. Or in favor of someone "recommended" from above. Or many other forms of nepotism.

I've seen wonderful managers-to-be being kept in a lower role because the company didn't want to cough up the increase in salary. And, as said before, invariably I've seen these people end up leaving and going somewhere else, causing the department a few problems (organization, lost know-how...).

BTW, reading my comments on this one might think I'm bitter and maybe I am: I worked 6 years in Spain and France, where nepotism is the norm and techies are considered second class citizens. I must say that I don't think I've been skipped for promotion many times and personally I haven't had many issues moving up (and down) the ladder in all the places I've worked. But I also know that one of the reasons for this is that I've never had a problem with getting up and leaving a company if I wasn't happy.

<comment><USER6> Your comments aren't wrong, but this illustrates why it's important when interviewing for jobs that you're interviewing them for cultural fit and to determine whether you'd want to work for your boss-to-be, almost moreso than them interviewing you.

<comment><USER4> Yep, and it took me years to learn that lesson :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> > Companies don't need to go so far as the well-known Google 20 percent time

A bit of a digression here.

I love that people think the idea that letting employees spend a measly 20% of their time deciding what they should be working on is somehow an extreme idea. What portion of your typical day would you honestly say is devoted to solid, in-the-flow work? After all the meeting, context switches, random interruptions, lunch, distractions on company chat -- I personally would say a fraction. Or flow state is simply dead for me at the office.

Recently, my roommate and I came home after work and ended up knocking out a very useful skunkworks project in about 6 hours over the course of 2 nights. That completely uninterrupted time mixed with the fact that it was a project that was freshly conceived and still full of passion in our minds let us get more work done in that burst than we felt like we had in weeks.

20% time is a joke. We need to ditch this 40 hour, strictly scheduled workweek in distracting office environments and try some radically different ways of getting productivity boosts. It just so happens that people also feel a lot better when they get these boosts to boot. I know after knocking out that project certainly made me feel awesome.

<comment><USER8> Maybe I'm exceptionally lucky, but I work from home most of the time and get to prioritize my work myself. If I want to spend a day improving test coverage or build tooling, I am free to do so.

The price I pay for this is earning about 10k€ less a year, but I still think it's worth it.

<comment><USER9> Just for fun I wondered what a missed $10k/yr was over time.

[http://www.moneychimp.com/calculator/compound_interest_calcu...](http://www.moneychimp.com/calculator/compound_interest_calculator.htm)

values of 0; 10,000; 20; 4; results in nearly 310k of missed gains.

Increasing that 4% to 8% increases it to nearly a half a million!

At my estimated retirement income requirements, that basically means I could quit working 10 years earlier if I don't settle for being underpaid.

<comment><USER10> Eh, you'll save thousands by not having to commute.

<comment><USER9> Or the other option, work remotely and not get underpaid...

</comment></comment></comment></comment></comment><comment><USER11> This practice can easily be abused or/and cause unintented consequences. For example, once employees know this is a short cut for promotion, they will focus a lot of their energy and attention to find 'the void' and try to fill it, or act like they can fill it, thus neglecting the real work that need to be done.

In fact, this could be a cultural issue where everybody tries to act like taking a lead (usually by blanket emails including the management team that say "XXX has been launched!! Contrats Y!!"), however you will find behind the backdrop, things are just half-baked or down right totally fake, because real execution is boring and not getting attention. So once an excitement dies down, people will scramble to find another 'void' to fill. You may argue the manager can check the work, but in a big cooperation, the middle managers are most vulnerable, and thus they care much more about their own asses than to ensure their staff get real work done.

In other words, this tactic is only applicable when the company is small, say, less than 20 people, and the boss knows everybody and the projects well.

<comment><USER12> I completely agree. Leaving a gap and waiting for someone to fill it is practically the _opposite_ of management.

 _> ..once employees know this is a short cut for promotion, they will focus a lot of their energy and attention to find 'the void' and try to fill it, or act like they can fill it, thus neglecting the real work that need to be done._

This in particular is really dangerous because it can poison an organisation's culture. For example, imagine Ben decides to focus on managing upwards in an effort to get Adam to promote him. Meanwhile, he neglects his duties, forcing his team-mates to pick up the slack. They start getting annoyed at Ben because he's not pulling his weight.

It's not uncommon, in my experience (and I'm aware that I'm at risk of stereo- typing here), for good, smart, conscientious people in technical roles to focus first on doing the job that they've been assigned and trust that management will recognise and reward them for doing so (and, conversely, punish anyone who slacks off), _and_ that one of those rewards is that they will be considered for any opportunity for promotion that arises. Unfortunately, that doesn't always happen.

If Adam promotes Ben, his old team-mates are going to be _really_ pissed off. From their perspective, Ben's bad behaviour has been rewarded, instead of rectified. Meanwhile, the extra work they've been putting in to make up for that bad behaviour has been completely ignored.

The end result is an unhappy team, They'll resent both Ben and Adam, their productivity will probably drop (because whey the hell should they work their asses off when they're clearly not going to be rewarded for it?), and may well start looking elsewhere for work.

In that scenario, Adam has _not_ done a good job as a manager, and he's _definitely_ not a good leader.

There's nothing wrong with identifying a gap and opening a dialogue about how it can be filled (including asking if anyone's interested in filling it) but if someone moves to plug a gap, that generally means that they're going to leave a gap somewhere else. A good manager needs to make sure that they understand the implications of shifting people around, and explicitly recognise the indirect contribution that Ben's old team-mates are making to fill the gap.

Organisations are about teams, not individuals. It's astounding how many managers fail to grasp that.

<comment><USER13> Organisations are about politics and status. As a sideline, sometimes useful work gets done.

>In that scenario, Adam has not done a good job as a manager, and he's definitely not a good leader.

One difference between good and bad management is that good managers understand politics, they understand people, and most of all they understand the consequences of different political options. (I mean effective and ineffective, not good vs evil.)

Effective managers don't - ever - rule by formula, campfire or sports coach platitudes, or read-it-in-a-book business mythology.

So if you're dealing with someone who does any of the above as a first choice, they're unlikely to be making rational choices, or to have any deep understanding of the team(s) they're managing.

Evil managers can have a good understanding of consequences but their choices will be designed to increase their own income and status at the expense of their team/company. So they can appear to be doing stupid counterproductive things, but in fact they'll likely be promoted because they're gaming the system. They're a horror to work for, because they'll exploit their team as a resource and discard it without looking back. (I've seen people boast about this. It's not hypothetical.)

Good managers have an interest in developing the talent in their team _as well as_ shipping good things and getting themselves promoted. But they won't be doing it with platitudes like "Leave space for people to act like managers" and then punishing anyone who actually does. They'll be more politically adept than that.

The big problem for employees is that politics and culture are invisible. I've seen plenty of management books, but I can't remember seeing a useful book that explains the practical differences between exploitation/support and good/bad good/evil management. Simple metrics like hours worked are a start, but a bigger picture with standard examples of management practices and styles, and supportive/unhealthy team cultures would be very useful.

</comment></comment></comment><comment><USER14> Sorry for another negative post. As a PM, the example stated seems a bit absurd and definitely not the environment for me.

A transparent and healthy company culture lets people (briefly) reason and talk about projects/strengths. There shouldn't be some sort of implicit beauty contest, rewarding aggressive employee who are underloaded.

There must be better ways to develop talent. The method listed also creates a lot of weird incentives/strategies if employees know what is going on.

<comment><USER15> Agreed. You really hit the nail on the head when you said "aggressive." This strategy seems like it would create an artificially competitive zero-sum game within the company where employees who should be working together are competing to be the golden volunteer for the boss.

I think it would be better to always have fewer tasks than people (not more tasks, like the author seems to suggest), but establish high-level goals for the team as a whole. You'll quickly see who is best at understanding the goals, turning them into work, and recruiting other people to help do that work, which is real leadership (not just jumping to do extra tasks).

<comment><USER16> And if there is important work that has not been staffed with a person, then was it really important in the first place?

</comment></comment></comment><comment><USER17> In a world where there is no judging, this could work well, people would do things out of interest and want, but in this world, I feel this is more "gamification". This is because people will take these hints because know they are an explicit vehicle to get noticed and they know that _not_ taking the hint will cost them. It's playing with (psychologically manipulating) people.

That's to say they do it because in this game it's beneficial to their career/image not because they sincerely _want_ to. It's making the brownnosing opportunities explicit, I guess.

It also practically makes people work "on a curve" the baseline is the "best" worker now, the person who has no other responsibilities, the workaholic, neurotic, perfectionist, etc. and now everyone else gets (unfavorably) compared to this one.

It's the difference between going to the toilet and on the other hand, choosing to eat ice cream. One is a must, the other an option which you may or may not act on.

<comment><USER18> Thanks you just expressed perfectly my thoughts on this.

</comment></comment><comment><USER19> I think this is one of the arguments for holocracy. The entire purpose of management is to efficiently assign work to individual contributors. Instead of leaving a few work items unassigned, holocracy leaves _all_ the work items unassigned, and then the ones that get done are the ones that are most important to the team.

I'm not saying I buy the idea, and in fact that the same arguments against holocracy work against the author's approach.

        Instead, at the next department meeting, I talked about how impressed I was
        with what those teams had done, and how it was going to be important for us
        to spread that good practice to other teams. Without explicitly saying so, I
        let it be known that this was something people could work on.

And what if nobody had stepped up? Would the author have left it at that, undermining their political power by showing that they could be ignored with no ill effects? Or would they have then appointed someone to force continuous integration upon everyone (thus creating resentment due to the false choice presented)?

If you're going to manage, manage. If you're going to be hands-off, be hands- off. But this half-and-half nonsense combines the worst of holocracy and traditional management.

<comment><USER20> If nobody steps up then it's quite likely that work never needed to get done in the first place. win-win as long as it's a learning experience for all involved.

It's definitely a problem if you force a team or a person into a certain pattern and then change the rules without telling. For example you may have punished someone for taking the initiative in the past and now you try to intentionally create a vacuum.

In the real world there is always vacuum and always stuff people think needs to get done that doesn't really need to get done. The illusion is that the manager is omnipotent and can see all the vacuum and inefficiency. A good manager works with the team to understand those.

<comment><USER21> > If nobody steps up then it's quite likely that work never needed to get done > in the first place.

Seriously? Consider this: You have all people tied up in work for one month. A customer issue comes up. Who should step up to take it? Because you're not seriously suggesting it should rot there one month, do you?

It's a classical coordination problem (and that's why preemptive scheduling was invented). I, as a developer, have no idea if I should step up. I would have to asses importance of all the other work that is being done by others, just to get a boolean value out of it. So everybody has to switch context to examine the issue, and the everybody's tasks to see where it fits in the grand scheme of things.

Now you can say, OK, we will have priorities on things, easy. But then you actually find out that the low priority work doesn't get done at all. OK, so you start to calculate time slices, fair scheduling, all that jazz. And all of sudden everybody is forced to execute these overcomplicated scheduling algorithms and no real work gets done. It's a bureaucratic nightmare (because people are really bad at executing algorithms correctly, and have high task switching overhead), and I have seen it. While this could be sanely done by a single responsible person, project manager, who has an idea about:

(1) what is the priority (and required latency) of each work item

(2) how long things are going to take (estimate)

(3) what are the dependencies

(4) who prefers what kind of work

Furthermore, if he needs any help with these points, he doesn't need to ask the whole team. Only one person can assess importance of an issue; the others do not need to care.

<comment><USER20> > A customer issue comes up. Who should step up to take it? Because you're not > seriously suggesting it should rot there one month, do you?

That's why you talk to each other. Unless the team is huge than figuring out who works on something shouldn't take a long time.

> the low priority work doesn't get done at all.

That's great. Low priority stuff shouldn't get done ahead of high priority stuff.

IMO you're over-complicating some things and over-simplifying others. There is no mythical project manager who can tell your items 1-4 in anything but the most trivial of projects. That's why almost any complex tech project I've seen managed by Gantt charts and project managers (and I've seen lots) never meets their schedule. Once you let go of the illusion that you can actually manage technology projects that way you'll find things get a lot simpler.

Here's what happens in real life with your items 1-4:

(1) The priority and require latency are often misjudged by the project manager. In technology project project managers often don't have the right domain knowledge to be able to judge these. So they may prioritize some feature ahead of another in a way that makes it more difficult to build the system.

(2) How long things are going to take is impossible to judge in an R&D scenario. Only projects that are very similar to ones you've done in the past can be estimated with any certainty. In practice most project managers will make an estimate that fits what he's asked to deliver on because he is anchored to that.

(3) Requires domain knowledge that the project manager doesn't typically have. Even individuals in the team may not have it. The team as a whole can usually figure those out by discussion. In real world projects managed by project managers dependencies are discovered when work is blocked due to them more often than predicted.

(4) This is also difficult. What tends to happen is the project manager will have some thoughts about who prefers what kind of work. Sometimes they'll be wrong. People get upset. People leave. It's easier for people to work on what they like in a less tightly managed environment.

A lot of this is cultural. In some cultures and for some people being self managed is extremely difficult. I've worked with people who will stress out if they're not told what to do. However, I do believe the best teams consist of people who are more self managed.

</comment></comment></comment></comment><comment><USER22> I've worked at too many places where the vacuums are real, not contrived as bounty, and NO ONE WANTS YOU TO FILL THEM. They all really, _really_ just want to spin your wheels, stay on the treadmill, and count paper clips until your dying day. Everyone.

The real-world dynamic, on the other side of the wall, is more like that of some kind of 1950's sitcom depiction of a social circle of married couples, and all the lazy husbands resent the one that buys his wife roses, and makes them all look bad.

</comment><comment><USER21> While I quite agree with the idea, it rests on the assumption:

"leaders also need to create a culture in which employees do not have every waking moment of every day committed to project work"

Unfortunately, I am currently in situation where is lot more project work than people (and I wonder, is it different elsewhere?). In that case, I don't think the approach the author describes quite works unless you have a dedicated person who keeps track what needs to be done and prioritizes (i.e. project manager).

Because when I work on something I want to work on it with highest possible focus, not being bothered to asses what other work has to be done. So I would prefer (which is not my current predicament, sadly) some _other_ person tracking everything and telling me - hey, this thing has higher priority than what you're doing right now, perhaps you should switch tasks. The point is, he should make the calculation that I should switch, not me.

(Perhaps this is a reason why preemptive multitasking won over cooperative multitasking on the OS level?)

<comment><USER23> There are some, who in ambition to lead (or work on highly visible projects), will step up and take on new things – meanwhile skimping on their core responsibilities and deliverables.

Are these the people we want to promote into leadership roles?

<comment><USER24> What about people who have a light load during a cycle (due to specialization), like to tinker with things in their 'spare' time, or would rather tradeoff their core and do something different?

Seems reasonable for an internal tool or process to help the team - not a necessity, so if nobody wants to do it, no big deal. If people are excited about it, it'll get done along with their core responsibilities.

The other case is giving people the opportunity to hand off their normal load (that may be uninteresting to them) to head up some project or initiative that would have to be assigned to someone anyway. In the latter case, isn't it better to have someone who's interested doing it than have that person doing uninteresting work while an uninterested person heads up the project?

</comment></comment></comment><comment><USER25> Fuck ambition for its own sake. It only causes a race to the bottom and short- changes users/customers.

I have used this strategic vacuum technique as a manager to great effect before.

It brings out the best creativity and allows people who are going through apparent productivity lulls to come out of them in a healthy, smarter way. It also builds lasting loyalty and a strong team spirit.

Velocity isn't just hours spent butt-in-seat or number of commits or whatever. It's precious moments of high quality attention. To maximize that you need to be more like a conductor of an orchestra than a drill sergeant.

CAVEAT: when under a high-pressure situation with a new team it is sometimes necessary to limit freedom, demand trust, and command things for the purpose of getting through that situation. Obviously it's dangerous and the wrong kind of manager can get addicted to this kind of solution easily. These temporary command-and-control moments can sometimes be used as trust builders for the managers if, once the situation is resolved, they immediately relinquish the extraordinary power they had used and return to a more natural/creative dynamic - the team will see this as honourable since it didn't technically _have_ to happen that way.

</comment><comment><USER26> This idea is based on a premise I don't think is at all obvious: that the person who volunteers for a job is necessarily the best person for a job.

</comment><comment><USER27> I've heard this approach mentioned before, but it was in the context of how to hire hotel maids, as explained by a Four Seasons Hotels executive. They like people who are a bit obsessive about tidyness, and have a way to test for that.

This is a good approach to cleaning up a room. It may not be appropriate to programming.

</comment><comment><USER28> I am 100% pro this approach. Of course it won't work for 80% of companies with rigid control and hierarchy but I never had much interest in working for such companies.

Maybe I am too old but I remember days of programming being pure fun and maybe it is not typical but I can choose such jobs even today. If it does not sparkle there is no amount of money that can make me join the team.

Programming was (and is) the thing of passion and joy. If you don't have fun you're holding it the wrong way. Having 'fill the gap' tasks is brilliant way to keep the team engaged the right way. It won't work for sweatshops but why would one work in such company in the first place? Money is no excuse just to be clear in advance.

Unless it is thing of love and passion and fun it is not programming in the first place.

</comment><comment> d--b To start acting as a manager is actually not to jump into the vacuums that you see everywhere as a developper. Acting as a manager is to take a step back, and help others fill in the vacuums.

</comment><comment><USER29> Let me take a look at our Jira queues.

Confirmed, leaving work unassigned doesn't get anything accomplished.

</comment><comment><USER30> I don't understand how this would work reliably, honestly. My first impression is that there are just too many variables involved. I can see this favoring the "gotta get it now" crowd.

<comment><USER14> Especially if employees know their manager/org does stuff like this, employees will almost like bidders in a game theoretic auction; trying to keep flexible schedules, predicting the likelihood/quality of other vacuums coming up, evaluating how they stack up against their colleagues, etc..

I can imagine unhealthy situations where employees feel obliged to take on a vacuum, or have to compete for a vacuum they don't actually want.

</comment></comment><comment><USER16> An alternate take on work voids and volunteering:

      Asking for volunteers (or implicitly relying on volunteers) is one of many
      structures companies can choose to allocate work. Like many other minimally-
      structured structures, it tends to reinforce and amplify larger cultural
      inequities.

[http://sasha.wtf/relying-on-volunteering-is- unfair/](http://sasha.wtf/relying-on-volunteering-is-unfair/)

</comment><comment><USER31> Getting a promotion to a good position requires all of the following:

1\. The company must be growing non-linearly and be strong financially. 2\. You must have enough value to the company where if you leave you'll be difficult to replace. 3\. Management prefers to promote from within.

If any one of these is missing, then the positions offered as promotions will be sub-optimal.

#1 seems to be in short supply across a large swath of industries, and is the main driver for lack of promotions offered these days.

</comment><comment><USER32> One issue here; what if the people working in the organisation already have too many things to work on and there's no one who feels they can take on this task?

Seems like the article and its title assume that a workplace necessarily has lulls between tasks (or perhaps more employees than there is work available). By assigning people tasks, you can at least tell them that their new job is more important than their current one, at least at this point in time.

</comment><comment><USER33> In my corporate experience, only doing what you're told to by your manager is the route to mediocre raises and rare promotions. Larger raises and faster promotions come from identifying problems and solving them, i.e. not needing to be micro-managed.

<comment><USER34> Large raises and faster promotions come from your perceived value and nowadays is mostly achieved by networking and politics. Identifying problems and solving them is often a threat to all levels above you, often managers play games by introducing inefficiencies and then pretending to solve them slowly, keeping their perceived utility and visibility high, and you identifying and solving some of these poses an existential threat to their fiefdoms. If you can identify/solve problems, start your own business and have your old company becoming your customer instead.

<comment><USER33> In my experience, when layoff times came around, the managers would get rid of those they didn't want any more, and it was always the deadwood, not the high performers. I infer they viewed the deadwood as much more of a threat.

<comment><USER34> I've seen grade-A employees being kicked out during layoffs and deadwood remaining, so YMMV. A lot of it depends on the company culture and on the personal goals of managers and their ability to sell whatever they intend to their higher ups.

</comment></comment></comment></comment><comment><USER35> Shouldn't someone ready to be a leader recognise the voids without them being explicitly pointed out to them?</comment>


Unbundling, Duck Duck Go, and Native Advertising - <AUTHOR> http://runtimeintrospection.tumblr.com/post/101344879837/unbundling-duck-duck-go-and-native-advertising

<comment><USER2> Sales = helping people pick the thing they know they want

Marketing = figuring out what people might want and giving them guidance

Domain knowledge is helpful for both of these, but so is contextual history. That is why Pinterest is so brilliant. They are building a highly personal style graph and in many ways, that will be easier to monetize than Facebook's social graph.</comment>


Gas Lights: How We Erased Darkness from the Night [video] - <AUTHOR> https://www.youtube.com/watch?v=qTiNAgFMgWM <comment><AUTHOR> I recently decided to start a new video series on the modern history of light.

You may be surprised to learn that street lighting (as we know it) was relatively uncommon until the mid 1800s. Up until about 200 years ago, new lighting technology developments tended to take place centuries apart. That all changed with the advent of open-flame gas lighting.

In the first video in my Story of Light series, I cover the development of gas lighting, the pros and cons of the technology, and the inventions that led to its downfall. If you know where to look, however, you can still find gas lamps today.

<comment><USER2> I went to wikipedia to look up coal gas, which you mentioned in the video but didn't link to: [https://en.wikipedia.org/wiki/Coal_gas](https://en.wikipedia.org/wiki/Coal_gas)

My dad's house was built in the mid-1990's. It has custom fluorescent bulbs that are probably rated at 5000K. They're "okay", but only because the bulbs are entirely hidden on top of cabinets or high in the ceiling, and filtered through the tan paint on the walls. I found some 2200K COB LEDs that I intend to install on those light circuits, as the other lights in his kitchen are a case study in poor lighting practices.

His kitchen has canister lights. The stickers say "max 40w", but he had 75-watt equivalent 5000K CFLs in those canisters. They were terrible. I found a box of 2700K 60-watt equivalent LEDs in his laundry room, and switched them out while he was traveling. At the time he was like, NO I'M OLD I NEED SUPER- BRIGHT LIGHTS, but now he uses those lights instead of ignoring them. They're still too bright, but at least they're usable now. I recently found some 15w and 25w incandescent bulbs: the canister lights directly above the counters would be fine with 25w bulbs.

In your future videos, I'd be interested in comments on the dark-sky movement, efforts to prevent skyglow, how people commonly use too much light at night, and the abandonment of good lighting practices in the name of energy- efficiency: glare, "daylight" LEDs, broad-spectrum streetlights, etc.

OH, and I'd be especially interested in the difference between 5000K fluorescent and supposed-5000K LED bulbs. I'm sure the spectral power distribution of the supposed-5000K LEDs is totally different than 5000K fluorescents: lots of blue with just enough ROYG to trick people into thinking it's 'white' light (LED) vs. a relatively-flat power distribution (fluorescent)?

<comment><AUTHOR> Definitely! That's where I want to take the series, to talk about the modern health, safety, quality of light, and light pollution concerns. So I appreciate that feedback.

Regarding 5000K fluorescent vs. LED, actually the fluorescent will be way more spiky, with multiple spikes. A typical daylight LED spectrum is a spike around 450 nm, then a drop, then the rest of the colors from green to red.

[0] compares some different spectra, although most modern 5000K LEDs will tend to be a bit higher in the red area. I would say the warm white LED, cool white LED, and daylight spectra are a bit exaggerated/too ideal in this comparison.

What emits most of the visible light in fluorescent vs. LED is actually almost the same thing: a phosphor that converts UV (fluorescent) or blue (LED) into white light. But the actual chemical makeup differs between LED and fluorescent.

There are some new LED technologies that flatten out the spectrum. These typically employ a violet pump (around 415 nm) or some combination of violet, blue, and cyan (around 490 nm). But it's the phosphor engineering that actually does most of the flattening. We're only just starting to see these become available in finished products, however.

[0] [https://thegreensunshineco.com/wp- content/uploads/2018/09/le...](https://thegreensunshineco.com/wp- content/uploads/2018/09/led-lighting-2.jpg)</comment></comment></comment>


A simple framework for developing Linux kernel heap exploit - <AUTHOR> https://github.com/djrbliss/libplayground/ <comment><USER2> Anyone know of something like this for other platforms than linux?</comment>


Hugo Static Sites (part 2): GitHub and Forestry (CI and CD) - <AUTHOR> https://forestry.io/blog/up-and-running-with-hugo-part-2 <comment><AUTHOR> This is the second part of a 2-part series on using the Hugo static site generator. Part one is here: [https://forestry.io/blog/up-and-running-with- hugo/](https://forestry.io/blog/up-and-running-with-hugo/)</comment>


How to Calculate the Value of a Like - <AUTHOR> http://blogs.hbr.org/cs/2012/11/how_to_calculate_the_value_of.html

<comment><USER2> While I'm all for measure ability on social media, this is again snake oil: oversimplification of how social media works and where it can actually benefit your business.

I think the biggest sin is the sin of omission: the only use case it caters to a direct transaction business, say, e-commerce. What about social activity for engaging with customers, say, what a local mom-pop store may want to do. What about building brand affinity, something larger brands want to do. What about giving users a forum to connect with the brand at multiple levels. How about a place where you can make accessible certain contact points, say, customer service, or simple stuff such as table bookings at a restaurant. And the above list is by no means exhaustive.

Even in the specific use case of e-commerce, it makes an over simplistic assumption of effectiveness = instant conversion. What about a guy who discovers something through the Facebook feed, does some comparison shopping, and then goes on to the site to finally buy that same product. Basically, the formula is an oversimplification of the buying process, even for the narrow scenario within which this works.</comment>


Day in the Life at Rdio: Ryan Sims - <AUTHOR> http://designerfund.com/bridge/day-in-the-life-rdio-ryan-sims/

<comment><USER2> I think Rdio is great, but unless I'm missing something, this isn't meant to be a joke. It just needs a line next to one of the images saying something like "Ryan is significantly cooler than you can ever hope to be".</comment>


Arq 2 (OS X backup-to-S3 software) has been released. - <AUTHOR> http://www.haystacksoftware.com/blog/2011/08/arq-2-is-out/

<comment><USER2> cache: [http://webcache.googleusercontent.com/search?sclient=psy&...](http://webcache.googleusercontent.com/search?sclient=psy&hl=en&biw=1514&bih=1015&source=hp&q=cache%3Ahttp%3A%2F%2Fwww.haystacksoftware.com%2Fblog%2F2011%2F08%2Farq-2-is- out%2F&pbx=1&oq=cache%3Ahttp%3A%2F%2Fwww.haystacksoftware.com%2Fblog%2F2011%2F08%2Farq-2-is- out%2F&aq=f&aqi=&aql=&gs_sm=e&gs_upl=8698l11226l0l11425l8l7l1l0l0l2l225l989l1.3.2l6l0)

<comment><USER3> It's back up, and cached. Sorry about that!

</comment></comment><comment><USER4> Arq does incremental backups... but does it do incremental _restores_? i.e. if I have already restored the backup to another computer, can I later fetch just what has changed? This is the only feature missing from duplicity[1] to make it perfect.

[1] <http://duplicity.nongnu.org/>

<comment><USER3> No, but it's on my to-do list. It'd be awesome for, for example, restoring from an older Time Machine backup (fast) and then merging in the latest Arq backup.

(I wrote Arq)

</comment></comment><comment><USER5> Nice. I checked, and the source to the restore tool has been updated too:

<https://github.com/sreitshamer/arq_restore>

(I haven't run a test restore with it yet, though.)

</comment><comment><USER6> Nice! I've been using Arq for some time and it's great for selective backup (I use Backblaze for bulk backups.) Stefan, the developer of Arq, is also quick to reply and very helpful.

</comment><comment><USER7> Could someone explain the benefit of backing up to S3 as opposed to just a service like Mozy, Backblaze, or Dropbox?

<comment><USER8> It's probably a little cheaper, plus you have slightly more control over it.

<comment><USER7> I think Backblaze offers unlimited for $6/month, Mozy offers 125GB for $10/month.

That same pricing $0.140 per GB (on S3) is $17.5/month unless I misunderstand S3 pricing.

<http://aws.amazon.com/s3/pricing/>

<http://mozy.com/home/pricing/>

<https://secure.backblaze.com/buy.htm>

Dropbox is more expensive but is syncing as opposed to backup.

<comment><USER9> I don't think you misunderstand S3's pricing. They're not cheap. What they are is flexible, generally-high-availability, and you can choose the region you want to serve out of. For sheer storage costs, they're moderately high, same as their EC2 costs for sheer compute power.

<comment><USER10> ... which is why it's inappropriate for a desktop backup solution. The chances of simultaneously losing your hard drive AND the entire RAID array in the Backblaze container that stores your data are so small that it's not worth paying extra.

<comment><USER3> If Backblaze loses your data and it's your only backup, you need to re-upload all your data. If that takes a long time and your hard drive fails during that time, you lose your data.

(disclosure: I wrote Arq)

<comment><USER8> I think with remote backups, a 2-part backup is probably the best strategy. Time Machine or Carbon Copy Cloner on an external hard drive, and remote backups with Arq, or BackBlaze, or Carbonite, or whatever.

It's possible to lose your S3 data too (and then you're in the same situation as BackBlaze losing your data). For example, I once accidentally removed all permissions from files in a bucket with Transmit, including the permissions to read files or set permissions.

I think Arq is great, just playing devil's advocate.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Just use Crashplan - <http://www.crashplan.com/>

Unlimited backups on one computer for $50/year (USD) - <http://www.crashplan.com/consumer/store.vtl>

Encrypt your files with your account password, a passphrase, or a local encryption key. Incremental backup and lots of other goodness.

<comment><USER12> ^ astroturfing

<comment><USER13> Given that the account was just created, I tend to agree. Which is sad, as Crashplan is a genuinely good product (disclosure: I've been using it for 2+ years and am paid up for the next few years). It gives fine grained (up-to- the-minute) off-site backups w/versioning and easy restores (I've only done one-off restores, not full disaster recovery).

I've used it in production and personal environments.

But I hate the idea that they are farming out this kind of astroturfing. Gack.

<comment><USER11> Nah, it wasn't astroturfing; I lurk most of the time. It does everything that submission does, does it well and does it inexpensively compared with rolling your own or having to deal with the vagaries of S3 (who lost S3 and EBS data irretrievably in the EU last week).

So you can downvote me, but don't think that it was Code42 doing it - I have no relation to them.</comment></comment></comment></comment>


A Surprisingly Underutilized Tactic for Getting 20% Plus More Ecommerce Sales - <AUTHOR> https://capitalandgrowth.org/articles/1689/a-surprisingly-underutilized-tactic-that-can-help.html <comment><USER2> This article doesnt read very legit, I'm sure it's a useful tactic but claiming that a complex behavioral phenomenon is controlled by a single gene that's being investigated using crispr is, well, questionable at best and it doesnt lead to a lot of confidence to the validity of the rest if the arguments made by the article</comment>


These phone apps have got your number - <AUTHOR> http://www.bbc.co.uk/news/technology-38103895 <comment><USER2> This really gets my goat. Just having my number is one problem. Handing out willy-nilly to anyone who asks for it is unethical. Unfortunately, no one seems to really care in India. Everyone wants the comfort of knowing who is calling them. Blocking telemarketers seems to be high on the priority list.

This is frustrating for someone who is developing an address book app. I cannot believe that people keep asking us to provide 'truecaller' functionality! I even have a one-star review on the app store because I don't hand out numbers like these apps do. I have seen some other apps gradually given in and add this functionality because of user pressure.

In short, the apps are probably doing it because they are afraid of losing users and hence money.</comment>


Seven Day Roguelike (7DRL) Challenge 2010 starts March 6th. - <AUTHOR> http://groups.google.com/group/rec.games.roguelike.development/browse_thread/thread/96fae2f059d0b2b2?pli=1

<comment><USER2> I wish that, rather than building another game with rich play but steep learning curve for all the keystrokes, somebody would take Falcon's Eye (<http://falconseye.sourceforge.net/> ) a little farther.

</comment><comment><USER3> Hey thanks for posting this - it is great to get a reminder of these kind of upcoming events/challenges/contests :)</comment>


Wanna buy a television station? - <AUTHOR> http://nathansandbox.appspot.com/

<comment><AUTHOR> Nathan here - just chiming in that I'm willing to answer questions here as well as on email.</comment>


Mac OS Evolution: From System 1.0 to Snow Leopard - <AUTHOR> http://blogof.francescomugnai.com/2009/11/mac-os-evolution-from-system-1-0-to-snow-leopard-55-wonderful-images/

<comment><USER2> Go to <http://www.guidebookgallery.org/screenshots> if you want to see more (also: screenshots from many other operating systems of past times).

GUIdebook sadly only goes up to 10.3 Tiger – would be really great if someone would pick up the work.

(I especially like GUIdebook's comparisons of different system components like here: <http://www.guidebookgallery.org/screenshots/splash> I would argue that it's immediately obvious which is the classy OS :)

</comment><comment><USER3> I feel old.

Up until a few years ago I had original, shrinkwrapped Copland (what was to be the new Mac OS, pre-Next acquisition) demo disks. That isn't to say it was working code or anything, it was more of a promo "here's what it's gonna look like".

I'm so glad Copland didn't work out. Funny thing is, I actually have owned only Windows machines since about Mac OS 7 or 8, so I essentially haven't gotten to use the Mac since it's actually had the more modern architecture.

I do have an iPhone, though, so I guess that counts. :)

</comment><comment><USER4> The oldest Mac system that I remember using was System 7.0. The screenshots took me back to the good old days when I was child in elementary school, playing around with Kid Pix. I remember I used to love using the "explode" tool.

Apple sure has changed a lot since then.

<comment><USER5> Oh No!

(I love KidPix)

<comment><USER6> I'm slowly working on a similar app. It's not polished enough to even call it a beta yet, but you can check it out at [1]. I've got a nice tool plugin API, but my graphics system needs work. Improvements are in the works.

[1] <http://www.steveasleep.com/splatterboard>

<comment><USER5> It's been so long that recalling all the reasons KidPix made me happy would be impossible. But I can remember spending hours using that app, doodling, making little movies, and just enjoying everything about it. Little touches like the "Oh No!" sound effect made the app so much fun to use.

The app was bought (along with the rest of Broderbund's IP) and resurrected a couple years ago:

<http://www.mackiev.com/kid_pix.html>

Not sure if it lives up to the original.

<comment><USER6> That incarnation of Kid Pix looks like a bit of a monstrosity, lacking the spirit of the original.

</comment></comment></comment></comment></comment><comment><USER7> Actually, the System lineage died with MacOS 9. Rhapsody and OSX are really direct descendants of NeXTSTEP and, thus, are a completely different family. OS 9 lived on, for some time, as a subsystem of OSX for PowerPC.

<comment><USER8> True, especially if you're looking at what's "under the hood". But visually, there are a lot of continuities between the two, and of course the user base largely transitioned as if 9->X were just another upgrade like going from 6.0.7 to System 7.

</comment></comment><comment><USER9> Steve Jobs in his first meeting with execs after he came back said Apple products had lost their sex appeal. Take a look at the leap Mac OS made after he returned.

</comment><comment><USER10> This is a great reminder of what's stayed the same more than what's different. Or, at least, how gradual the change has been. The jump from 9.x to 10.0 is surprisingly subtle compared to the jump from 9.x to Snow Leopard.

<comment><USER11> Great point. Apple seemed to take the NeXT OS and try and mask it to resemble the visual functionality of OS 9 as much as possible.

Anyone remember the OS X beta with the blue apple in the middle of the menu bar? Yikes.

</comment></comment><comment><USER12> Wow, that was really a trip down memory lane. The first mac I ever owned (a Mac Plus) was System 6... inits and cdevs. I had a lot of fun learning to program on one.

</comment><comment><USER13> I went to art school and was a designer for a short stint, where Macs completely ruled supreme. I learned and completely grocked the living hell out of OS7, 8 and 8.5. Despite their incredibly archaic architecture under the hood, they are still probably my favorite operating system. Interface wise, OSX has actually been a step back in a lot of ways.

<comment><USER14> Really? The menu bar at the top is basically the same, albeit squishier than before. They added a dock, and a ton of chrome. I'm not seeing how anything was "a step back" by any means. The only irk I really have is lack of keyboard navigation on dialog boxen. I should be able to hit tab or arrow keys or something to switch between buttons on dialogs (example: the shutdown menu) - but that's _always_ been the case, it's nothing new. Care to elaborate, or even take to task some of my assertions?

<comment><USER15> Control+F7 (or System Preferences > Keyboard Shortcuts > Full Keyboard Access: All Controls). Then use Tab and Shift+Tab.

Also, for shutdown dialog (and other) navigation is not needed at all: Return = default button (Shut Down), Space = alternate (focused) button (Cancel).

<comment><USER14> That tip on full keyboard access is pure win. If I could up-mod this comment a dozen times, I would! Many thanks! This has pestered me for about a decade now.

</comment></comment></comment></comment><comment><USER16> This really drives home how bad the space-based ("Aurora"?) theme of 10.5 and 10.6 is: when we look at this in ten years, I think the screenshots of 10.5 and 10.6 will have aged the worst.

There's something timeless about the earlier Mac OS versions. 10.5 and 10.6 are just kitschy.

<comment><USER17> Really? I have the exact opposite reaction. Every development in OS X has made itself more subtle. Gradients are lighter, windows are softer... The unified 10.5 theme got rid of what I felt was a kitschy plastic feel in the system, and it created a much more intuitive menu set-up where buttons are a part of the top bar. 10.6 takes steps even further — I love the new Dock menus and hope that's the standard from which Apple develops its new look. Some things moved backwards — the new iTunes got _more_ gradient-y and that's an issue — but in general Apple's design is growing more and more subtle.

The default backgrounds are a little silly, yes, but I think when we look back we'll view it like we view 60s typography — perhaps a bit gaudier than we needed, but it was done in a sense of fun rather than a sense of self- importance. The space-age design feels to me like a wink.

</comment></comment><comment><USER18> According to Wikipedia ([http://en.wikipedia.org/wiki/History_of_Mac_OS#System_1.2C_2...](http://en.wikipedia.org/wiki/History_of_Mac_OS#System_1.2C_2.2C_3_.26_4)), System 2.0 is from 1985, not 1987 as listed.

</comment><comment><USER19> At least one of those images (<http://winmac.emuunlim.com/Images/Screenshots/OS8.jpg>) is a _terrible_ Photoshop job.

<comment><USER20> It's WinMac (as evidenced by the URL) - some hacks that let your windows machine look like various flavors of the classic MacOS

<comment><USER19> Aha... so, yes, a terrible Photoshop job. :) The progress bars are particularly galling - they don't even line up with the frame properly.

</comment></comment></comment><comment><USER21> Wow, that brought back some memories. I wrote a commercial app for the Mac in 1984/85 but I had forgot how the original Mac screen looked.

</comment><comment><USER22> Looking over these things, I realized why the Mac platform is not properly metal. Its volume only goes up to 7.

</comment><comment><USER23> Gads! Those shots of Explorer 5 gave me some horrible flashbacks. My first mac, Mac II System 7, fond memories</comment>


Ask HN: How do you write and maintain email templates? - <AUTHOR> We've got this legacy system running on LaTeX, but it's a huge pain in the ass to update. I'd like to go toward a more web-standard based system. With SCSS compilation, maybe componentized UI. For companies with lots of email types, what does your email stack look like? <comment><USER2> I'm not sure this is useful (I'm not a tech guy in any way, just interested in the discussion) but for our stack we use third-party tools, and we really like them: SendWithUs for transactional emails, Gorgias for email templates, and RocketBolt for tracking the emails.

</comment><comment><USER3> The last few times we've done it we used Zurb Foundation for Emails[0], built with Grunt, and sent using Mailgun.

There's still a lot of manual work, but we've created a lot of code template/mixins that get put together during the build process. As you well know, building good looking emails is a pain in the ass.

<comment><AUTHOR> Glad to hear. I'm building a similar system with Gulp and Mandrill. Thanks.</comment></comment>