Scala is for drivers - <AUTHOR> http://blog.fogus.me/2011/09/02/scala-is-for-drivers/

<comment><USER2> Ever since I watched a Java developer at a client give a rabid "Why Scala is OMFG AMAZING!!!!!" talk to a bunch of bemused Perl programmers ("and it has this thing called a map and it has this thing where you can execute some code for each element of a list inline and..."), I've been carrying around the following prejudice, which I'd like to be freed from, so help me out:

There are only two types of people who find Scala even vaguely interesting:

\- Java programmers who have never used another reasonably powerful high-level programming language

\- Programmers familiar with high-level programming languages who have a need (or want) to target the JVM

What am I missing here?

<comment><USER3> It's a hybrid OO-FP language that is statically typed with decent type inference. This has never been done before.

Perl is not statically typed. You might think that's a good thing, but I don't because I routinely refactor in a large code base. I can make one change and start propagating it around until everything compiles and unless I've made a mistake it will all work. I don't make very many mistakes so I can improve a code base at rapid speed.

<comment><USER4> Ahem, once you have used OCaml, which _is_ a hybrid etc etc, you would never say Scala has decent type inference. I have to annotate my Scala a hell of a lot more than my OCaml to get it to compile. All function arguments for example, whereas OCaml just deals with it with no fuss.

I understand this is because Scala can't use Hindley-Milner due to some OO reason or other but still.

<comment><USER5>
        due to some OO reason or other

Overloading would be that reason.

</comment></comment></comment></comment><comment><USER6> I'm not sure I agree with the article. Given that Scala has tried to encompass every paradigm except 'goto', it's hard to argue that Scala is a carefully tuned high performance machine (e.g. a specialty sports car, that Alfa romeo). Rather, Scala is a bit like a Java that had been 'improved' by the Windows Team. Lots of pieces of flair, plenty of buzz words and a very complicated UI/language. As a car, it seems more like a combination between the Alfa, a Zamboni and 18 wheeler.

<comment><USER7> If you compared Scala to C# you'd find that Scala has many features absent in C#, like a more powerful type inference engine, implicits, pattern matching, a better module system, and traits. C#, however, has many language features Scala doesn't, like dynamic blocks, unsafe code, unsigned arithmetic, a built- in events system, built-in LINQ syntax, real reified generics, and so on. Yet no one complains about C# being a kitchen sink language!,

It turns out, Scala isn't hard because of all its language features. There are other languages that easily comparable in size to it and also support multiple paradigms. It has some syntactic flexibility that some people find offensive, but it's certainly not the difficult part of learning Scala. Scala is difficult mainly because it is so well designed that it easily enables the use of functional patterns that most people aren't familiar with. This means that to use it you have to learn a new paradigm, and most people aren't willing to put in the effort to do so.

<comment><USER8> "Scala is difficult mainly because it is so well designed that it easily enables the use of functional patterns that most people aren't familiar with."

I hear this argument a lot, but I don't think it's true. I've done a fair amount of haskell, OZ, lisp in various forms, etc, etc. I often have a hard time reading scala code, more so than any of these other languages which are also FP. Maybe it's just me, but it sure seems like other people have had the same experience. I've begun calling it statically typed perl, because my experience with it is very similar.

<comment><USER7> I haven't used Oz at all, and don't feel like comparing Lisps to Scala right now, but I would agree with you that functional code that I've seen in Haskell looks a lot cleaner than it does in Scala. Haskell is, of course, in many ways a narrower language in scope. It doesn't support subtyping or an imperative style, and doesn't have to deal with the constraints of running on the JVM or Java interoperation. I would say that, in general, the Haskell community are much less interested in Haskell becoming a widespread or pragmatic language.

I feel like the compromises Scala makes are valid. I guess in the end though if you feel like Scala is unreadable then it is not the language for you. Since Scala is something I believe strongly in, I wish there were a way I could help make it more readable for you! As someone who knows both Perl and Scala well, I feel like there is a whole world of difference between the two.

<comment><USER9> _It doesn't support subtyping or an imperative style_

I would argue that monads are the ultimate imperative style.

I would also agree that Haskell users have very little interest in it becoming mainstream.

My main gripe with Scala (in which another developer in my compilers class used it, not me), was that when reading his code I saw a lot of "magic." I'm not sure if that was better or worse, just... different.

<comment><USER7> There are few things that seemed more magical to me at first glance than Haskell's point-free style! :)

I would explain the difference between Perl magic and Scala magic as being that Scala magic reduces down to a relatively few simple but flexible rules, whereas Perl magic reduces to a bunch of edge cases and special rules that lack any form of cohesion. Once you learn these rules, reading Scala code becomes very manageable.

I found the Haskell code I saw to be clearer because it's type system allows one to omit types much more frequently, its indentation and function declaration style let you avoid a lot of curly braces and parenthesis, it's type class system involved less syntactic ceremony than Scala's implicits, point-free style allows one to omit Scala's underscores, and so on. All of these things added up so that in the end, I felt like Haskell just looked a lot nicer, much more concise and like the math it was trying to express.

I'm sure some of the authors of Scalaz could do a much better job than me explaining Haskell's advantages over Scala when writing functional code, since I am by no means a Haskell expert.

<comment><USER10> _Perl magic reduces to a bunch of edge cases and special rules that lack any form of cohesion._

I can think of two general philosophical premises which underlie most of those special rules in Perl: implicit variables and context. Most tutorials and books explain them poorly, which is why so many people never understand them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Since there are a lot of comments that disagree with the post, I'll say that I largely agree with its essential premise which is that a language's perceived difficulty shouldn't be based simply on the initial learning curve, but on how much it helps (or hinders) once it has been properly absorbed.

My only evidence for this statement is my own experience. I am well on the right side of the java curve as the article describes and over the first hump and well down it on the scala curve.

<comment><USER7> In support for your statement I'll add my own experience.

As a language expert, I've become more proficient with Perl the language than most people I know who program in the language daily. Perl has a tremendous number of nooks and crannies to explore and is so complex that as far as I know there are no other implementations of the language besides the original. However, having mastered Perl, I am still far less productive using it than any of the other several dynamic languages out there that let you accomplish the exact same things but without all the extra complexity.

Scala had the opposite effect for me. Having reached a certain level of proficiency with it, many times I feel like I can express my ideas in code faster in Scala than I can in any other language. If Scala had faster compile times and a more Unixy library (not likely, given its Java heritage), I would even replace my use of scripting languages with it for small tasks!

<comment><USER12> When you say you "can express my ideas in code faster in Scala than [you] can in any other language", I'd love to see you expand on this. Why is it more productive for you than say, F#, or Haskell, or Python, or Clojure?

I don't say this to dispute your findings -- as someone potentially interested in learning Scala, I'm genuinely interested in any specifics you can provide. Thanks!

<comment><USER7> Well, a lot of coding comes down to data structures and algorithms, and I feel that Scala has the best out-of-the-box collections library experience of any language I've used. This makes it easy for me to choose an appropriate data structure and write my code as a series of transformations on it. I also like to think in terms of objects and Scala has the best fusion of OO and functional that I've ever seen. Finally, for most problems I like having a type system to help catch errors and to help shape the design process, and I like the IDE and tooling support that comes with it.

That said, I've never written a line of F# and have written very little Haskell and Clojure. Clojure also seems like a fine language to get things done if it is more your cup of tea. If I were to pick a Lisp for development, Clojure would definitely be it.

<comment><USER13> I think Scala is a wonderful language, however it is one of many.

Data structure and collections support in scala is equivalent to any functional language. I would be interested in hearing where you think Scala offers more.

F# is another functional language that balances OOP in a way that works well. It is different to but homomorphic with Scala's OOP functional synthesis. Both allow a very unique style with algebraic types, matching objects, structural recursion and monad syntax.

</comment></comment></comment></comment></comment><comment><USER14> What's worse than a blanket assertion that one language is hands down better than another? Defending that assertion with trite infographics and limp analogies.

If you're in a technical leadership role and convinced that Scala is better than Java then run your team on Scala and take a quantitative look at the results - bugs, developer happiness, velocity, etc - all the myriad dimensions of development.

Anything else is just anecdotal, an assertion, fluff.

<comment><USER5>
        better than another?

Where did I say that? This post was about complexity curves observed during my experience. I can say I like Scala better than Java, but I wouldn't assert that is indicative of anything that you should believe. Decide for yourself. (although it sounds like you might have already)

        Anything else is just anecdotal,
        an assertion, fluff.

And what are the measurements that you describe? They're certain not science. But yes you're right that this is anecdotal. That was the entire point.

</comment></comment><comment><USER15> What are these "incidental complexities" and "type system inconsistencies" the author speaks of as keeping Java from becoming second nature?

There are probably literally a million Java developers who have reached a point on the learning curve where it feels second nature, makes sense in the larger context, stays out of the way (except for a thing or two), and lets them focus on the problem at hand.

The latest argument I've heard for Scala is that its complexity and difficult to read code is a plus, because only really smart and dedicated programmers can handle it. It's a "filter". I like that one. It soothes egoes while simultaneously allowing results-oriented businesses to dismiss it.

</comment><comment><USER16> Am i missing something here? From what I know of Alfa Romeo's they're gorgeous but about as reliable as driving around a faberge egg.

</comment><comment><USER17> Comparing Scala to Java is not the point. You should compare it to Clojure, ABCL, or Groovy.

</comment><comment><USER4> Scala is to Java as F# is to VB.

</comment><comment><USER18> We can put an end to discusion if we just port Haskell to the JVM. (Edit: i hate my silly cell phone. Spelling!)

</comment><comment><USER19> So a self-confessed car hater is going to make his case for Scala using a tortured car metaphor. It doesn't come across well.

A good driver can take a slow car around a track quicker than a bad driver can take a fast car around a track.</comment>


Gangs of Los Angeles (2019) - <AUTHOR> https://www.google.com/maps/d/viewer?hl=en&mid=1ul5yqMj7_JgM5xpfOn5gtlO-bTk&ll=33.93271669763388%2C-118.2654736888648&z=11 <comment><USER2> Note: if gang names look like they are 14 year old's xbox live gamertag, its because many gang members are in their teens</comment>


How to Hire Your First Engineer - <AUTHOR> https://blog.ycombinator.com/how-to-hire-your-first-engineer/ <comment><USER2> These are good points for finding your first engineer, but here is a tip for helping close your dream hire: _offer more equity._

Your first eng hire will shoulder nearly all of the technical burden soon after as the founders transition into more of the non-technical roles (sales, outreach, recruiting, fundraising, business strategy). The amount of blood, sweat, and tears poured in by the first eng hire is somewhat less than a founder, yes, but not the 30-50x typical equity ratio we see today.

<comment><USER3> Depends on pay, right? If you are offering employee #1 market pay, why would you give them 10% equity? That is potentially millions of dollars for not taking a risk.

I have been on both sides of this, and have thoughts. What do you think is fair for employee #1 making at or near market rate?

<comment><USER4> Even if you pay your #1 employee at market rate he is taking huge risks and should be compensated accordingly. Working at an early stage company often comes with huge job insecurity, loss of medical benefits more mature companies might be able to offer (better insurance etc.) and a possible kink in your CV (3 years at Microsoft look much better than spending 3 years at an unsuccessful company that eventually shut down).

To sum it up, I would expect a #1 engineers equity to be at least half of a founders equity AND payed at near-market rate.

<comment><USER5> lol @ startups with no engineers yet paying "market rate"... they will _maybe_ pay market rate within their stage band i.e. compared to other SV seed-stage startups, but this will still be _way_ below the liquid total comp at a post IPO tech company. At this point in the tech cycle the math is so out of whack in favor of big co that I can't with a straight face recommend to anyone that they join a seed startup as an early employee engineer unless they're already well off financially (5-7 years ago I felt like I could). There are exceptions, of course.

<comment><USER6> Yeah but those exceptions are pretty big. The hiring pipelines at FAANG are so over-tuned for false negatives that there are plenty of engineers who are good enough to work at a FAANG for FAANG-level compensation yet are not actually getting offers from FAANG companies. They're on the market for (market minus FAANG)-rate compensation.

Then you have to remember that FAANG companies are large enterprises, by definition, and that comes with a lot of overhead - design by committee, politicking between middle-management fiefdoms, not being a part of the conversation when irrefutable directives are issued by executives four levels above you, varying levels of paperwork and documentation that are necessary in large organizations. That's soul-sucking for a lot of people, and those people will exclude themselves from FAANG-level compensation, and are on the market for (market minus FAANG)-rate compensation.

The real reason why a lot of founders can't hire at market rate compensation is that any early employee, even if you're paying them market rate, needs to buy into your vision just as much as you do. The upside for early employees, even more than potential compensation, is in being a strong influence, including at relatively senior levels, as the company grows. If, as an IC, you find yourself being recruited by somebody who you think is a strong and experienced leader, selling a product that you personally think is important, then you grab the bull by the horns and get on. If somebody who rambles and can't make eye contact asks you to join to build out Uber-for-pidgeons, it doesn't really matter how much compensation is being offered; you're going to walk away.

<comment><USER7> There are many companies that offer pretty good pay and great job security outside FAANG. Try Microsoft, Oracle, Siemens, Airbus, SAP or one of the million medium sized companies whose name you've never heard of unless you're in the same line of business.

<comment><USER8> My experience has been that those companies (except for Microsoft and Oracle) have been well below FANG compensation levels, while being in line (and sometimes lower) than what I can get from later stage startups and not much higher than I have heard from early stage startups. I have only looked for opportunities in NYC and Dallas, though, so that might skew my observations.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Anyone else getting a little tired of the immediate reduction of any conversation around early-stage startup job opportunities to "comp vs FAANG"? As someone who spent the last 5 years in early stage startups, before recently accepting a FAANG offer, I'm starting to realize folks who only think about comp probably aren't good fits for startups. Here are a few quick reasons to take less comp at a super early stage startup:

\- You will develop a wide breadth of skills you simply can't develop at FAANG, as you will be involved in product meetings, business strategy conversations, and will regularly eat lunch with the CEO. I imagine the reverse of this is true as well, in that there are skills developed at FAANG that are hard to develop as employee <50.

\- You will get to fast-track your career progression, in that you will be in line for promotions much earlier than in large companies, as opportunities emerge.

\- Companies (including FAANG) will look for folks with your skillset (my startup experience was a huge plus in my recent job search).

\- You will work on hard problems, with passionate people; folks aren't punching the clock here. This is fun.

Also, for folks just thinking about comp, I'd like to gently point out that a 40 hour week on work you feel "meh" about is ~35% of your waking life. That's not to say you can't find exciting work at FAANG (I hope I have), but rather that there is more to a job than comp or career progression, and working with passionate folks on hard problems can be incredibly fulfilling.

Edit: formatting

<comment><USER10> As someone who did a long string of failing small companies and finally settled in among the FAANGs, I respect your experience but disagree with everything you said.

Wide breadth of skills? If you're hired as a code monkey you're going to monkey code. Nobody ever asked me what I thought about the latest business partnership or synergy strategy. Just code.

Career progression? Another nope. With only a few people in the company, you can't go up and you can't build a team under you. Who are you going to manage? There's nobody under you! My startup coworkers used to jokingly give each other fake "Senior Director" titles which were meaningless of course because there were two managers in the whole company, one was the CEO. Even if you did somehow get a fancy title or a team under you, and got bought by a big company, you're back to "3rd engineer from the left" in their hierarchy.

Hard problems? I don't know, not in my experience. Just problems unappealing to the bigger players.

And for all that you risk the company not being able to make payroll or canceling your benefits. Sorry, I can say definitively that working at small companies probably set my career _back_ 10 years.

EDIT: I suppose it's highly dependent on the company.

<comment><USER9> I think your edit hits the nail on the head, as we've clearly had different experiences.

I should clarify that a lot of the hard problems at early stage cos are around creating something that is not only new, but is also a viable business, with minimal resources and huge time pressure. Whether the technical side is hard or not is another question entirely.

Anyways, thanks for the comment — in addition to providing a good counterpoint, it's a good reminder for me that my experience is neither universal nor even necessarily the general case. YMMV.

<comment><USER11> I wonder, how often "huge time pressure" is more imagined than real. Unless "time"="investors".

</comment></comment></comment></comment><comment><USER12> I've been hired as Engineer #1 at two startups (both doing well). I wrote some thoughts recently about how I was recruited into that role:

[https://twitter.com/philfreo/status/1012171080834969601](https://twitter.com/philfreo/status/1012171080834969601)

On the hiring side, I also incorporated some hard lessons learned about growing our Eng team from 2 to 14 here:

[http://philfreo.com/blog/when-who-how-to-hire-an- engineering...](http://philfreo.com/blog/when-who-how-to-hire-an-engineering- team-including-hiring-remotely/)

<comment> mark-r I've done the #1 employee thing too. The founder was someone I had worked for previously. He was technical enough that I didn't have to worry about growing the team from there, he handled it all.

</comment></comment><comment><USER13> I remember hearing as a high schooler that The Italian Mob acquired great loyalty through only hiring people whose family they knew or had met before. Maybe a dumb metaphor, but the painpoints, lonely nights, long hours and competing offers you're gonna face with your Engineer #1 are going to require some deeply rooted trust.

We're lucky enough to live in a time where our skills are in great demand and compensation can be matched without blinking an eye - my advice to business minds hiring their first engineers is to get to know them, build trust and find the ones who are committed to building cool shit with you for the long haul. Don't just make it about comp and perks.

> As I said at the start, hiring your first engineer is incredibly hard unless > you're lucky enough to have a friend you can convince to join

<comment><USER14> "Comitted to building cool shit" is not a motivation that will persist through hard times.

<comment><USER13> Maybe you didn't make it this far

< Don't just make it about comp and perks.

</comment></comment></comment><comment><USER15> As engineer no 1 at an early stage startup, you don't need ths same skills that are needed at FAANG. I may be wrong, but you are constantly iterating and mostly building software that has a shelf life of may be 3-6 months. You are not building for reliability or scale. You are building mostly ad-hoc and to fulfil an immediate market need (which may or may not exist 2 months from now). Where as at FAANG you are by design building for reliability and scale from day 1. Very different skills.

I can't comment which skill is more valuable. They are somewhat orthogonal to each other right ? The better you get at software engineering the more process oriented you become. Hopefully an early startup gives you that kind of progression, but very unlikely, since the progression is directly correlated to the startup's scale and success.

If someone desires to put good software engineering into practice from day 1, then engineer #1 at an early stage startup is not the right choice.

This is all based on anecdotal experiences so am happy to stand corrected.

</comment><comment><USER16> An interesting exercise: assume the first engineering hire you want has to be at least the senior engineer bar at a top tech firm.

In order for the engineer's median compensation to match the median compensation he would make working at FANG, how much stock would you have to give them making reasonable assumption about valuations (ie, assume your start up will have a trajectory in the top 30% percentile, but not in the top 0.1%).

<comment><USER17> I think FANG is not the right group to look at when it comes to "top" tech firms unless you also mean other companies _like_ FANG wrt how competitive they are, such as MS, unicorns, hedge funds, etc.

Depending on what you're making you also might be doing yourself a disservice by only wanting to hire from "the best" - if you're making a simple website or CRUD app as part of a larger business strategy such as online ordering, you don't need to hire an expert in big data

</comment></comment><comment><USER18> I wonder what proportion of HN would have different careers if software engineering paid, say, as much as humanities while humanities paid like software engineering. It seems like everyone here (myself included) isn't really in it for the money, but who knows what would happen.

<comment><USER19> I love engineering. But you know what, when rent is $3000+ per month, there's only so far my rational mind will let me go.

I loved art and drawing too. But I wisely chose not to master in art when going to college.

<comment><USER18> Yeah, same. I think I could have enjoyed going into history but the huge salary disparity certainly helps make the choice between two otherwise more or less equal paths.

Also, rent in some cities might not be as much if fewer people went into tech ;-)

</comment></comment></comment><comment><USER20> Almost all the early employees I have met in successful startups have been towering contributors to say the least. Many of them enjoyed very very comfortable jobs in FANG (or equivalent money companies) before taking this up OR moved into one afterwards.

Unless the startup founders themselves are technically up to the bar required, I would think this is going to require huge motivation to make folks like that join. That can be either in the way of convincing them with your software potential enough for them to make the switch OR a ton of money/equity (And not FANG level money, even better). I would go with the latter in 90+% of cases, probably both.

IOW - I don't think we have a proper market place today that serves these high tier developers who will single handedly make or break it for you. I don't think the normal recruiting methods apply to excellent established candidates. You might luck into one, but it is going to be real hard unless you draw from known sources.

FWIW, I am very curious if there is one such premium marketplace as well. (Sorry if this sounds gentrifying, but there are a bunch of engineers I know whose gross comp is close to 1MM/yr or more and I don't think you are going to find them prowling LinkedIn or responding to regular methods anytime soon. Anecdotally I do believe many of them have the capacity to do magic technically though).

</comment><comment><USER21> How have we ended up with "engineer" as the only acceptable job title for people who build software? What happened to programmer? Developer? Or even (glances at title bar...) Hacker?

</comment><comment><USER22> I find it interesting how many startups try to remove all bias from the hiring process, make interviews as objective and metric based as possible, but in the end, personal connections (friendships even) are still most important for your first hires.

<comment><USER23> There is so much risk in hiring an early employee, it's totally reasonable to try and only hire from a personal network for the first three.

Managing great employees can be challenging; managing someone you don't know is great can be 10 times more difficult.

</comment></comment><comment><USER24> 1\. Find somebody that is very good and passionate at something.

2\. Present your idea the best you can.

3\. Only hire if he/she is interested in your idea.

4\. Offer stake in your business so it is also his/her business.

<comment><USER25> Why would I be interested in _your_ idea? More than likely you aren't trying to feed starving children. I might pretend like I'm interested, but at the end of the day, it's just a paycheck.

<comment><USER26> > it's just a paycheck

This is probably part of why it's hard to find a good first engineering hire -- for better or worse, most engineers aren't a good fit for that stage of a company's growth.

<comment><USER25> Doesn't the founder have the same motivation? To make money?

<comment><USER26> Founders do not treat their company as "just a paycheck". They're not just turning up to punch the clock. Early on, the company is their life -- their efforts determine its success, and their company's success is their own success. The same goes, to a lesser extent, for early employees.

Maybe that's not widely agreed, though. I saw an ad on the "Who's Hiring?" post this month looking for a first engineer with a broad and deep skill set and big responsibilities offering 0.2% equity... Essentially no motivation to move heaven and earth to make the company succeed. Shrugs.

<comment><USER25> _Founders do not treat their company as "just a paycheck". They're not just turning up to punch the clock. Early on, the company is their life -- their efforts determine its success, and their company's success is their own success_

Yes because they have a hope for a larger reward later.....

 _The same goes, to a lesser extent, for early employees._

Them not so much.

For instance Marco Arment was the first engineer at Tumblr. The exit was for $1 billion. He is rumored to have received less than $6 million.

</comment></comment></comment></comment></comment></comment><comment><USER27> Some traits I look for in engineer #1: a) should obsess about architecture and code organization (they will be laying a foundation so having a bit of OCD helps), b) should make good tradeoffs and optimize for speed (they will be building the wrong things initially), c) mature enough to understand that they will be writing and rewriting a lot (see (b)) and d) last but not least, should have a strong desire to do a startup (knowing all the risks)....

<comment><USER28> Don't you mean not optimize for speed, since they will be building the wrong things initially?

<comment><USER29> I think they meant optimize for speed of writing code not running it.

</comment></comment></comment><comment><USER30> As the first engineer at a successful startup.

Responsibilities- * Take over everything technical I was good at and hired for. * Take over policy and progress on everything I was good at. * Be on call 24/7\. * Do whatever the CEO/CIO didn't want to do.

Think this is pretty standard from my reading of other startups. The one lesson I should have learned and didn't is that as first engineer you should get 10% or more equity if you stay > 5 years.

</comment><comment><USER31> I think with a good business side you can get away with mediocre first technical hires, which you will probably end up with.

</comment><comment><USER32> How do you tell a good engineer from an average one?

If you can't do that then all the time you spend taking them out to dinner is wasted.

</comment><comment><USER33> Nice article.

On TripleByte - they should make it clearer that the platform is only for the Bay Area and Software Engineering.

<comment><USER34> I am being cynical but this article feels like a reason to promote/plug TripleByte complete with a $15,000 offer at the end.

<comment><USER35> The article offered no new insights, it was more like an infomercial for the author's company.

</comment></comment></comment><comment><USER36> Hiring is a difficult task that I'm currently in the middle of attempting, so Harj's article is something I recognize. I'm not after a first dev, but I am part of a team that is after a dozen or so devs and I've now been day 1 on three different ventures.

The problem is that the main piece of advice is correct but unuseful. Indeed, you should look at people you've worked with. In some sense they've all interviewed with you already, so you know what it's like to work with them, you know how good they are at communicating, and you know their limitations.

Unfortunately, most people haven't worked with enough people to have more than one or two likely candidates for whatever they're thinking of doing. Your homies are either not right for the role, unwilling to move from a position of comfort, or not willing to put your friendship on the line.

The same is also the reason why your company cannot grow via connections of employees past some point, the r < 1 on that series and it will converge on some low number.

Where my problem is a bit different to the article is that before you have any devs, you have a really big problem identifying good devs. Heck even hiring for devs outside your specialty is hard. If you can't do X, how are you going to find a good X? You will end up falling back on recommendations and reputation, and you'll pay up for a branded individual if one is around. Not in itself terrible, but every penny counts early in a startup.

I was talking to a shop who were after their first programmer a few months back, and they did the sensible sounding thing of bringing in a trusted friend from a FAANG to interview people. Main issue with that is that person is thinking about how a megacorp hires people. Mainly avoid guys who can't reverse a linked list, and stick the new guys into a process that already exists. But it's not quite the same things you care about as a day 1 startup.

Day 1 guys need energy. Sad to say it, but this probably tilts against people who have kids. In my first day 1 jobs, I didn't have kids, I could wake up at 6 and code to 11 at night. Or you do like my current firm, where I was also day 1, but let people work from home. Then you suddenly have a very big carrot for experienced hires. The guys in the previous paragraph did the same.

Day 1 guys also need a high degree of autonomy. When you've got nothing, as in not even a chat about what stack you're using, day 1 guy needs to put down those foundations. This is a lot harder than you think. Not only do you need to consider budget, you need to think about what a small team can do, you need to think about what imaginary future employees will want to work with, and you need a way to get from little team to big team where your hands aren't tied by your day 1 decisions. And you gotta balance current technical debt against future payments on that account.

You also need to be broadly read. You can be highly specialized, but you need to have some idea of what's going on in the software world in general. Chances are you will end up picking the most standard choice of everything that isn't your specialty, like Django for a web framework or SciKit for a bit of ML. But you need to have an idea about a huge variety of things to know what the landscape roughly looks like.

So how do you find a person like that? Well actually none of the methods other than "network" will actually check for these qualities. Most people are specialists with a label that enables them to move to other jobs with similar titles (Low Latency c++ dev), and recruiters are on the lookout for the label. Inbound and Outreach are also not going to tell you how broad someone is, because everyone writes stuff on their CV to look specialised, with a bit of breadth to catch a few interviews. Meetups, maybe, depends on how good you are at directing the conversation. A skill in itself.

</comment><comment><USER37> I think it is important to offer more equity to your engineers.

</comment><comment><USER38> How to make sure that you can fire your first engineer without too much damage? maybe state-by-state instructions...

</comment><comment><USER39> before you hire an engineer, make sure you have your onboarding streamlined

<comment><USER24> This is the worst advice. You don't want to spend resources on problems that are not yet even problems. Especially extremely early when you don't have any resources to burn.

One super power startups have is being frugal with money, why would you want to throw it away?

<comment><USER40> No engineer taking a role like this is going to expect an onboarding process. Many of them are specifically drawn by the idea they'll get to sit down and solve a problem on day 1.

<comment><USER41> > Many of them are specifically drawn by the idea they'll get to sit down and > solve a problem on day 1

I don't see how engineer #1 or engineer #100 changes that.

When I onboard a senior engineer, they get a problem on day 1.

<comment><USER42> The difference is that when hiring engineer #1 there's no technical infrastructure to which you'd onboard someone, and nobody who's really qualified to make a decent technical onboarding process - you're hiring a person to create this process (among others) from scratch, make the initial decisions themselves (instead of being told them during onboarding) and onboard others.

<comment><USER43> Onboarding become here are the bathrooms, there is a great place to eat down the street.</comment></comment></comment></comment></comment></comment>


Diabase's $5K USD, 4 or 5 axis 3d printer/milling machine - <AUTHOR> https://www.youtube.com/watch?v=LihlhFkAl54&feature=youtu.be <comment><AUTHOR> A review (sponsored by Diabase, I think) is here, as well: [https://www.youtube.com/watch?v=IZ82_L6UmzQ](https://www.youtube.com/watch?v=IZ82_L6UmzQ)

No financial connections to these guys, I just know them personally and think it is pretty cool tech, to have both additive (3d deposition) and subtractive (milling) in one machine. Plus laser scanning.</comment>


Blu-ray apparently isn't coming to Macs - <AUTHOR> http://news.cnet.com/8301-13506_3-20009391-17.html?tag=TOCmoreStories.0 <comment><USER2> He's right, but right now there is a lot of value in a player. Especially in places outside the US, here in Australia were only really just coming out of the dark ages of download caps, 8gig is still a sizeable chunk of download.

I think it comes down to the player cost, which would move the mac mini out of the range their comfortable with. Wouldn't surprise me at all if they do an about face and market a blu ray player as a great feature in a future product iteration.

<comment><USER3> Thing is, Australia will catch up - streaming is the permanent solution, Blu Ray is the last gasp of discs.

<comment><USER2> True they are, two things though.

1\. At very least they are still going to be strong through at least one more product cycle.

2\. For people not on the cutting edge of technology they are going to be relevant for some time, unless they decide just to stick with DVD's for the next 5 years.

<comment><USER4> As far as I can see, people are just sticking with DVD's for the next 5 years.

</comment></comment></comment></comment><comment><USER5> I do hate optical media, but the problem I have with this is that adequate 10mbps+ connections are still hard to come by in a lot of places. Adequate in the sense that if you have a few people in the house using the network at the same time, streaming high def video, gaming, downloading files, etc, there is a limit to what the bandwidth can handle. Also, it seems like (with Netflix anyway), I'll get the occasion when either my ISP hiccups, my router, or servers, that cause significant issues or completely prevents streaming. If I'm feeling the urge to still watch something in these situations, I just pop in a movie and enjoy the optical goodness.

</comment><comment><USER6> well, Blu-ray isn't that great. Jobs is right, the world is moving towards downloadable content.

The only viable long term usage for blu-ray would be backups. One blu-ray disk is roughly equivalent to 5 dvds in terms of storage. Unfortunately, in the coming years, blu-ray will become too small to be viable for backups, the same way dvds have become.

</comment><comment><USER7> The BD standard also includes support for downloadable and streamable content via BD-Live.

<comment><USER4> Sure, but who wants to buy an easily-scratched bit of plastic that actually has to be shipped around like a physical object if you're going to download and stream content?

</comment></comment><comment><USER8> I wish he would say why blueray sucks

<comment><USER9> Because he doesn't say it does suck. It's just not where he sees the industry moving. As any good executive, he tries to see where his market is shifting and makes the decision to go in that direction. It may cause some short-term pain but if he's right, then he's saved himself a lot of money by not having to do bluray development.</comment></comment>


Smart People Really Do Think Faster. - <AUTHOR> http://www.npr.org/templates/story/story.php?storyId=102169531

<comment><USER2> Ai. Once more a journalistic report that confuses having a high IQ with being smart. This is not the current thinking among the best researchers on human intelligence.

[http://www.amazon.com/What-Intelligence-Tests-Miss- Psycholog...](http://www.amazon.com/What-Intelligence-Tests-Miss- Psychology/dp/030012385X)

As the current researchers put it, you can be "intelligent" (= score high on IQ tests) without being "rational" (above reference) or wise (below reference).

[http://www.amazon.com/What-Intelligence-Beyond-Flynn- Effect/...](http://www.amazon.com/What-Intelligence-Beyond-Flynn- Effect/dp/0521741475/)

But this idea goes back a lot further, all the way to the beginning of IQ testing. Lewis Terman himself wrote, "There are, however, certain characteristics of age scores with which the reader should be familiar. For one thing, it is necessary to bear in mind that the true mental age as we have used it refers to the mental age on a particular intelligence test. A subject's mental age in this sense may not coincide with the age score he would make in tests of musical ability, mechanical ability, social adjustment, etc. A subject has, strictly speaking, a number of mental ages; we are here concerned only with that which depends on the abilities tested by the new Stanford-Binet scales." (Terman & Merrill 1937, p. 25)

Ian Deary has very trenchant comments on how poorly understood "ability to think quickly" is in his book Looking Down on Human Intelligence: From Psychometrics to the Brain

[http://www.amazon.com/Looking-Down-Human-Intelligence- Psycho...](http://www.amazon.com/Looking-Down-Human-Intelligence- Psychometrics/dp/019852417X/)

But, really, the obligatory link for any discussion of a report on a research result like that is the article by Peter Norvig, director of research at Google, on how to interpret scientific research.

<http://norvig.com/experiment-design.html>

Check each news story you read for how many of the important issues in interpreting research are NOT discussed in the story.

P.S. I saw another news story about this research announcement,

[http://www.newscientist.com/article/mg20126993.300-highspeed...](http://www.newscientist.com/article/mg20126993.300-highspeed- brains-are-in-the-genes.html)

and it included this interesting paragraph:

"Just because intelligence is strongly genetic, that doesn't mean it cannot be improved. 'It's just the opposite,' says Richard Haier, of the University of California, Irvine, who works with Thompson. 'If it's genetic, it's biochemical, and we have all kinds of ways of influencing biochemistry.'"

</comment><comment><USER3> This is really just pointing out that IQ tests are time based and so people who think faster do better at them. Measures of intelligence that are not time based might not show the same difference.

I often found in school / college that I could answer all the questions on tests and exams but not in the time given. It always felt a little unfair that others who were actually less capable sometimes got higher scores simply because they were faster at those parts they _could_ do.

<comment><USER4> Intelligence _is speed_ , but not in the linear way we think of it. When people think faster, they can put slightly more time into examining each possible solution branch, which allows them to discard the ones that resolve as "bad." This, then, culls those branches from their memory, allowing them to process the rest of the solution tree even faster. Someone who knows a little more CS than I do could actually give a definite answer to just how much faster it makes someone, assuming, just for the sake of argument, that solution trees are binary.

Anyway, there are certain problems that require a "minimum mental speed" to accomplish; Mensa test questions are basically designed so that your working memory capacity will be exhausted by extraneous branches unless your mind can cull them as quickly as it can think of them.

<comment><USER5> > Anyway, there are certain problems that require a "minimum mental speed" to > accomplish; Mensa test questions are basically designed so that your working > memory capacity will be exhausted by extraneous branches unless your mind > can cull them as quickly as it can think of them.

What about people who have a larger or longer-lasting working memory capacity? Or those who have better culling algorithms? They may be able to solve classes of problems that 'faster' thinkers could never solve. They might do well at the Mensa test but on a simpler speed-based test they could do poorly.

Intelligence is not speed.

<comment><USER4> You missed the symmetry of the equality. If you have "better culling algorithms", each branch gets culled away faster, so, on an EEG or a similar device, you appear to be thinking faster.

The reason I didn't mention the possible variation in working memory capacity was a single word that I left out, leaving it, like I said, to the Computer Scientist: "exponential." Every time your have an additional binary choice to make, your possible solution-space doubles. It doesn't matter how large your working memory is; as long as it's a fixed, finite size, an exponential growth in memory consumption will consume it with relative ease. The culling algorithm needs to be of a certain minimum efficiency to keep you from "blowing your stack" and losing your place repeatedly, and this is what is perceived as "speed."

I think you misinterpreted, though, that I meant that intelligence is the speed _at which you solve macro-level problems_. It certainly isn't. Intelligence is the speed at which you prune decisions; external to the mind, this affects the _confidence_ you can take in your assertions, not the speed at which you reach them.

The more confident you are in lemma 1, the more quickly you can _consciously decide to_ move onto lemma 2, and so on, but this requires some internal message passing that's much slower than the complete decision-branch path- finding "system call" in your mind. Your macro "problem-solving speed" is much more affected by the speed of the IRQ handler (the neocortex, I think), but if the system calls keep returning a low confidence interval, you have to keep consciously pulling apart intuitions into graphs of semantic knowledge, and passing each node to the path-finder in turn, until you feel sure enough of your decision to become aware of it. If your culling algorithm is more efficient (as directly measured by your score, not your time, on an IQ test) then you will become aware of things that others never will, because their minds are caught in loops that return false-negative confidences.

Sleep, then, gives your culling algorithm a larger fixed-bound on its runtime before it must return a confidence; this is why sleeping on something will let you make decisions that you felt involved too much complexity the day before. (Of course, sleeping does other things as well, like transferring things between short- and long- term memory (where they're stored--if they are stored --with a much lower path cost), and shutting off the neocortex so the mind doesn't constantly have to context-switch to ring 3 while it's trying to process things.)

<comment><USER5> I think you are focusing heavily on one particular model of an 'intelligence algorithm'. The model you are assuming sounds a lot like the type used for chess program. I played along with the 'culling algorithm' bit for the sake of convenience. But I'm not sure there is good enough evidence to assume that as the underlying model.

The definition of speed I am using is analogous to the clock speed or memory retrieval speed in a computer and it does seem at one level to be the way you are thinking of it as well. I think this fits in with what the researchers are measuring.

> The reason I didn't mention the possible variation in working memory > capacity was a single word that I left out, leaving it, like I said, to the > Computer Scientist: "exponential."

The memory requirements of a particular algorithm don't necessarily grow exponentially with the solution space or the input data. As with time complexity common space complexity relationships to the input size are n (you need to store at least the input), nlog(n), n^k and k^n. Most tractable problems would be nlog(n) or at worst n^k where k was small. The implication of this is that often small differences in memory can make a huge difference. Possibly you are forgetting that every extra bit of memory 'exponentially' increases the number of options it that can represent.

One of the first things you learn in CS algorithms is that the an efficient (let's say nlog(n)) algorithm running on a very slow computer will beat an inefficient one (say n^2) on a much faster computer. Sometimes resources such as memory will make the difference between being able to use an nlog(n) rather then a n^2 algorithm. To me this is a good analogue to apply to intelligence. For particular classes of problems (the harder ones) the better algorithm will trump a faster processor. Having a store of 'right algorithms' probably has a lot more to do with intelligence than raw thought speed.

Your view seems to be that the fundamental thinking algorithm is a fixed tree- pruning-like one. If it was then yes speed would be the main differentiating factor. I think this is the crux of our disagreement.

</comment></comment></comment></comment></comment><comment><USER6> _And Thompson notes that our brains, unlike our bodies, peak relatively late in life.

"The wires between the brain cells, the connections, are the things that you can modify throughout life," he says. "They change and they improve through your 40s and 50s and 60s."_

I wonder how this squares with the following --> <http://news.ycombinator.com/item?id=516949>

Do we peak at 27 or 60?

<comment><USER7> Both can be true - you can improve specific mental abilities by practice even in old age, but your overall mental performance will probably decline.

<comment><USER8> Neither could be true, in many ways we learn the most during childhood, and in a very short time (e.g language, motor skills, sight).

</comment></comment></comment><comment><USER9> I haven't taken an IQ test, so I don't know exactly what that is like, but I've taken PSAT/ACT/GRE/GMAT tests, and it seems obvious to me that your performance on those tests is greatly influenced by how fast you can think.

If the IQ tests are anything like the other standardized tests, it is of absolutely no surprise to me that quick thinkers have higher IQs and I don't understand why it should come as a surprise to anyone else. Furthermore, assuming that IQ score depends on quick thinking, I'm not at all convinced that being smarter implies that you think faster.

<comment><AUTHOR> You make a good point. A slow thinker might be able to accomplish great things given enough time. Maybe we should consider such a person intelligent.

But even then I suspect that a quicker thinker with similar experience would be able to accomplish even greater things in that same period of time.

<comment><USER5> It's possible though that this is analogous with running. An IQ test could be seem as a relative sprint whereas the business of solving genuinely complex problems might be a marathon.

A 'sprinting test' may actually provide a rough gauge of general fitness and physical ability - and in so doing be a rough predictor of marathon performance in the general populace. But at the higher levels those with fast twitch muscles are actually at a disadvantage in a marathon against those with slow twitch muscles. Extrapolating the sprint result to the marathon only works at the very crudest level.

Of course I'm not saying this is actually the case with intelligence but in certainly could be.

</comment></comment></comment><comment><USER10> I've always thought of myself as really slow mentally. It always baffles me when I see and hear people in an oral discussion come up with interesting thoughts _while they are talking_. For me it always takes a couple of days of silent contemplation to see the interesting implications of something.

When people talk to me I sometimes just can't hear what they're saying, but whatever it is I stash the sound of it somewhere in my head so I can focus on processing it once they stop talking. The problem is of course that often people don't stop talking and the stack gets higher and higher until the bottom falls out and I stop paying attention completely. And if there's a TV in the room, it'll suck me in before anyone even says a word, and they'll have to yell and wave to get me back.

But when it does work out, I can recall their entire monologue word for word. I can still recall some of the things people have told me as much as 15 years ago, word for word. (My memory is a total sieve for other things though.)

Regardless, I'm pretty capable of thinking "big thoughts", say a recurring closure and how it affects/relates to the scope chain, the call stack, the namespace chain (Ruby is _weird_ this way), and maybe a couple other complicating dimensions. It just takes a while to think big thoughts (though I've developed a gut feel for navigating scopes and such by now and it's pretty much instant).

All that said, I'm pretty sure it works this way for more people.

<comment><USER11> Don't fret, some believe Da Vinci and Einstein were the same way.

It's people like you that come up with the most worthwhile and well thought out ideas.

People like me (rapid prototyping/speedy hashers of ideas) are mostly useless. It's beyond words difficult for me to put feet to floor and completely formulate, systematize, and write out a philosophical idea.

I come up with neat ideas, but they die just as quickly.

I systematized the entirety of order and chaos once, connected it with primitive human origins, and have mostly let it lie and do nothing for example.

Useless.

</comment></comment><comment><USER12> Reminds me of the OODA loop (<http://en.wikipedia.org/wiki/OODA_Loop>).

If this is true, then it seems plausible to optimize for response cycle speed and iteration to evaluate solutions to problems, regardless of one's raw intelligence (whatever that means).

This measure does, however, tend to lean towards problem-solving speed as the primary indicator of intelligence and that's probably not the most accurate way of measuring it.

</comment><comment><USER13> The argument against this I've heard is that if a dog could think 1000x faster, it would still only have dog thoughts but a 1000x more of them.

There must be something more to intelligence than just speed. Perhaps working memory is very important? Perhaps it's just having the right software in your head i.e., knowing how to solve problems and frame things?

</comment><comment><USER14> These guys (<http://www.visualspatial.com/>) would not be happy with the way results of this research are framed.

This research seems to be suggesting that auditory-sequential (AS) learners are more intelligent, i.e., have higher IQ, than visual spatial (VS) learners.

If IQ is the measure of intelligence, then certainly, AS would be regarded as more intelligent. That is why AS learners do better at every single test that is timed or requires quickness of thought, be it SAT/GRE, mensa or job interviews at microsoft/google or a wall street bank or hedge fund.

</comment><comment><USER15> Speed has been inferred based on the connectivity of the anatomy. It's a fair conclusion to draw but speed, per se, wasn't measured.

<http://www.jneurosci.org/cgi/content/abstract/29/7/2212>

</comment><comment><USER16> Smart people tend to be good ping pong players too, if they try, because you have to process so much information in such a short time, and then act on it.

<comment><USER17> If you think while playing then you cant play well. I play reasonable good ping pong, and many times I am also watching me play.I do not know what I will do because I did not decide consciously.

</comment></comment><comment><USER18> Does it really matter whether you think faster or better, actually?

Life is not a 100m run; more like a marathon.

</comment><comment><USER19> It would be fun to know how "fast" my brain is. I'd pay multiple dollars to find out.

</comment><comment><USER20> time = distance/speed</comment>


11 Nerdy Facts About Bill Gates - <AUTHOR> http://www.easycppcodes.com/article/11-nerdy-facts-about-bill-gates/

<comment><USER2> Wish I was the owner of that house without the property taxes of course :)

<comment><AUTHOR> Dream House ___</comment></comment>


tink FAQ: A Package Unwinder for JavaScript (node.js replacement) - <AUTHOR> https://npm.community/t/tink-faq-a-package-unwinder-for-javascript/3191 <comment><USER2> Looks really cool!

<comment><AUTHOR> I agree, love the concept, let's hope they can pull it off.</comment></comment>


The Focal Camera – An open-source modular camera prototyping system - <AUTHOR> http://www.focalcamera.com/

<comment><USER2> At the start of the page I was really curious as to what image sensor they'd be using. Then I felt like an idiot.

<comment><USER3> I think the expectation of digital is not unreasonable, here. Most photos that get taken are taken on digital cameras.

Using a digital sensor would have several advantages in prototyping - you get a faster iteration loop of 'build camera, take picture, evaluate result', you can actually check for light-leaks in real time without removing film, and so on.

<comment><USER4> You could try to integrate one of these into the project: [http://www.bigshotcamera.com/](http://www.bigshotcamera.com/)

The only problem is that the sensor is probably tiny and any old lenses you might want to play with would have a massive telephoto effect, making focusing very difficult.

</comment></comment></comment><comment><AUTHOR> Album with examples: [http://imgur.com/a/XzVBq](http://imgur.com/a/XzVBq)</comment>


Don't offer co-workers help unless asked - <AUTHOR> https://msutoday.msu.edu/news/2018/keep-to-yourself-dont-offer-co-workers-help-unless-asked/ <comment><USER3> The article doesn't really distinguish between _offering_ help, and _pushing your help_. I work in a large team, and I often work on some obscure feature, and it's not always clear who has experience with it. If someone notifies me "hey, I have experience with that part of the codebase, I'm here if you need help", that's what I call _offering_ help, and _that_ is very useful. It's still up to me to decide if I need help or not.

<comment><USER4> If it's a large team how much time are they spending knowing what everyone else is working on?

<comment><USER5> This is when a team leader is helpful. He would say "Frank, I see that the bug that you are working is in the datafile handler. I know that Jill has has some experience in this area. Frank, could Jill provide some assistance here?"

</comment></comment></comment><comment><USER6> What if they are doing it wrong and I notice?

Do I wait until they are finished, and then fixing it will take so much longer... Or I can offer help earlier on and get it back on track sooner.

We have an issue here that someone will work on something for days or weeks and are producing complete garbage. But then when they've finished and they show the pile of crap they produced you can't tell them that's crap. As they've spent too many hours on it to redo it.

So if I see something like this happen, I'd rather "offer help" early on and try and get it onto a sane track and save a lot of headaches down the road.

<comment><USER7> > So if I see something like this happen, I'd rather "offer help" early on and > try and get it onto a sane track and save a lot of headaches down the road.

If you work in a kind of company where someone can work for weeks or months on some feature without any code review, design and architecture review, merging to mainline and testing processes, it's quite possible that the "complete crap" that "kinda works" is completely acceptable solution.

And it's like that in most of the enterprises.

<comment><USER6> It doesn't work though. The stuff that is made is often garbage performance wise, falls over a lot and ends up people spending hours trying to keep it running / restarting it.

We also have no testing process, no code review process. I find out about stuff when I have to fix a bug in it. That is often the first time I will see something that is deployed to production.

Also deploy is basically the drev works on something, which like I said is often garbage with no thought put into it, then just copies it to a live server.

I then get told it's not working and can I have a look, see that it looks like it's been writen by someone that suffered blunt force trauma to the head before they started and die a little inside.

Every. Godamn. Time.

I need a new job.

An example:

A database update that was taking 9 minutes to insert a few thousand rows. Why? Because it was a nested foreach loop with a sql call in the middle...

Or when they had an array (in C#) but they didn't know how big it was going to have to be. There solution was to make it way bigger than it needed to be, _by a lot_ , add to it. Then have a loop where they started at the end and resized the array by one item at a time until they had no more nulls... At least they left a comment in that saying someone needs to rewrite this as it was bad performance wise... I guess that's something.

<comment><USER8> Good christ, why would you use primitive arrays in C# like that?! How would someone not know about the _List_ class? It sounds like suffering from premature optimization, and then completely failing at knowing how to do the optimization part.

<comment><USER6> There are still some devs today that have years of experience that avoid List<T> because they don't understand generics.

Yes, honestly.

Or even better (worse), we have a database table that stores the state things. State can be one of a small collection of states, e.g. Foo, bar, Quax. It's enumerable.

How do we store it in the database table? as an nvarchar

Id = 1, State="Set State to Foo"

So any query was having to do a string parse to get the state out by grabbing the string after "Set State to "

Which was killing the database as the table has millions of rows and is used all the time.

I have so many examples like this.

<comment><USER8> The last time I ran into something this bad was ten years and two jobs ago when, in front-end JS, someone needed a lookup map, but instead of just using a JS object, he implemented an array where the even entities represented keys and the odd entities represented values, and for lookup he used a for loop over the even indices of the array to iterate through keys until he found a match. Yes, it was terrible. He came from IBM too.

I haven't run into anything that bad since; even my interns know a lot better. I'd suggest that if this is a routine problem for you, you might want to go find a team or job that has better programmers.

</comment></comment></comment></comment></comment></comment><comment><USER9> > Johnson surveyed 54 employees between the ages of 21 and 60 who worked full- > time jobs across a variety of industries, including manufacturing, > government, health care and education. He collected data over 10 days for a > collective 232 daily observations to assess daily helping, receipt of > gratitude, perceived positive social impact and work engagement.

So a way too small base to gather any helpful information from.

<comment><USER10> I agree, it was as well seasonal. Does not consider the types of task, the working dynamics, maturity of HR processes, distribution of tasks, how recently the employee was hired, overloaded professionals versus professionals with new tasks that needed to be learned. well at least the news did not present us with these data. this behavior study should have been placed in a bigger time frame, 1-2 years?

<comment><USER9> Also they should've limited the field of research. Pick one department, survey everyone in there for at least a year and see how that works out. I don't like these "quick results" studies because in the end, you have multiple faulty methods in there.

You will alter the study based on your assumption on what is going to be the result. If people know they are surveyed, they will act differently for at least a few weeks. If you have too many different departments, your results will vary so much, you cannot make any assumptions about the result. And on and on and on.

</comment></comment></comment><comment><USER8> And yet, the biggest team productivity issue I've seen is when people get stuck over their head and suffer in silence for days if not weeks on end, unable to make progress, while not asking for help. Just a tiny bit of help would go a long way, and looking to see when people aren't making progress and then proactively giving some pointers can save a huge amount of time. In older more complicated code bases it's often the case that there's some tricks or gotchas that only take 5 minutes to explain, but that could take weeks to figure out on your own without guidance.

<comment><USER11> This is huge.

My rule of thumb is that if you feel "stuck" for more than an hour you need to: (1) stop what you're doing, (2) go for a walk, and (3) let ~everyone know you're stuck.

If nobody can help because they don't understand what you're working on, then that's a huge red flag. You definitely should talk to them. The more people that understand that problem the better.

<comment><USER12> An hour is not enough time. That's barely long enough to have started thinking and researching a problem. Of course, it would probably make more sense to scale the timeout with the difficulty of the thing being done; if you're stonewalled on something trivial vs pondering architectural issues.

<comment><USER8> It depends on the scale of the problem. An hour is entirely too long to waste on trying to figure out which API method to accomplish a given task, but not nearly enough to spend on properly architecting a new system.

</comment></comment></comment></comment><comment><USER13> The comments here are far less insightful than I've come to expect from HN. It seems like this article has touched a (several?) nerve.

Can we just get the following out of the way?

1\. Sometimes it's good/necessary to offer help to inexperienced colleagues

2\. Sometimes that which is _called_ help is actually counter-productive or manipulative

The above are simultaneously true.

With that out of the way, a more fertile topic of debate might be how to distinguish the two scenarios. Here's a good start: [https://news.ycombinator.com/item?id=18290901](https://news.ycombinator.com/item?id=18290901)

</comment><comment><USER11> The abilities of offering and receiving help are like any other: they are skills that can be developed over time.

This is the topic of personal communication, and it is much more complicated then it is being given credit by the article. Furthermore, none of the experiences described match my own at Forestryio.

For example:

> Johnson explained that there are two basic kinds of help one can offer – > proactive and reactive help.

This is a pretty coarse simplification. Further, it does not describe how help is given at Forestry.

First, if I have no work queued then I will offer help to the team. This may be a specific offer, but I will state "I have nothing to do right now" and then I will ask either:

* Does anyone (needs help/want to pair/need some eyes, etc.) * What is the most important thing I could help with?

I am _proactively offering_ help, but I'm not forcing my way into their problem space. In a sense, I am proactively making it known that you're not going to fuck up my flow by asking me a question now.

Second, we really try to make it clear that if you're stuck on a problem for more than a couple hours. You should look for help–someone has problem been down this road before. Working in isolation increases the likelihood you're going to go down a rabbit hole and waste a bunch of time.

> What we found was that on the helper side, when people engage in proactive > help, they often don't have a clear understanding of recipients' problems > and issues, thus they receive less gratitude for it,

This just isn't the case at Forestryio. The team takes responsibility of the problems and issues, not the individual. If I offer to help and I don't understand the problem, then they will be explained to me. Having two people understand the problem is important. If they can't explain to me what the problem is (or admit that you're not sure) then why are they working on solving that problem?

> On the recipient side, if people are constantly coming up to me at work and > asking if I want their help, it could have an impact on my esteem and become > frustrating.

This is an ego problem. Grow the fuck up. Learning to _accept_ other people's help is a must if you want to work on a great team.

</comment><comment><USER14> I don't have an opinion on the findings, but can you really draw results from a single study with only 54 subjects? Specifically when something like this could differ across industries and those 54 are spread out among them.

<comment><USER15> The conclusions seem reasonable though. I.e. wouldn't you find it condescending if somebody offered you help when you didn't even hint that you could need some?

</comment></comment><comment><USER16> From a quick reading, it seemed this was mostly about people's feelings. In other words, the survey indicated that people feel better if they're not offered help, but instead get help only when they ask for it.

This seems reasonable, but it also seems a bit short-sighted; not _all_ that happens at work is about people's feelings, surely?

Sometimes making mistakes can lead to problems later, so stopping someone from doing The Wrong Thing(TM) ahead of time can actually help make them feel better in the long run, even if the immediate response is one of discomfort.

</comment><comment> EZ-E Related opinion : sometimes it's best to let the worst performing coworkers fail (if you don't have high vested stakes in the company)

<comment><USER17> but it becomes hard to rate performance. If they get stuck on a certain problem, they might be the 'worst performing' on that part, but they might have other strengths.

Judging who is performing bad across a large team is not (always) an easy things to do.

</comment></comment><comment><USER18> > when people engage in proactive help [...] they receive less gratitude for > it

OK, but what if maximizing gratitude is not my primary objective?

</comment><comment><USER19> We had this problem that developers didn't ask for help.

So we decided that if someone was stuck for more than 1h thinking about a solution to some problem it was against best practice not to ask for help.

Enforcing this policy didn't result in people asking more questions but instead problems being broken down to smaller sub problems. It was kind of a good thing.

</comment><comment><USER20> When I offer "help" it's usually because I noticed someone screwed up and my options are telling them to fix it, offering "help" in fixing it, or fixing it myself.

And if I'm offering that kind of "help" it's because it's not realistic to wait until I'm asked.

</comment><comment><USER21> Co-workers who have a tendency to "shepherd" newbies are downright annoying. Other than the initial on-boarding, there is no reason to be involved in solving someone's "new comer experience".

<comment><USER22> Not in all the cases IMHO. Sometimes a newbie is lacking experience and be might not be aware of that. He might get overconfident and cause troubles for other and himself. This is where "shepherd" would have helped. I had few mentors that just knew when to help out and what questions are on my mind and that helped a lot.

<comment><USER21> But this is exactly what the article talks about - and what I agree with - <USER2> them ask for help. To each his own, I agree that some people need that intervention, but for the rest of us, don't assume it.

<comment><USER17> I agree - but make sure you do let them know that it's okay to ask questions. Sometimes newbies might feel bad to ask for help.

I've had someone who recently graduated work in my team, who'd ask help and always apologize a ton of times for disturbing me whilst I had 'more important things to do'. Even though I made it clear quite frequently that I'd rather get disturbed rather than have him be stuck for hours on end.

Sometimes asking for help can make a new employee feel bad or judged and in my opinion, it is part of our responsibility to make sure this is not the case.

(Again, this does not mean to push your help, but just making it clear you are available in case they need you)

<comment><USER23> And some cultures may not feel they can ask for help.

</comment></comment></comment></comment></comment><comment><USER24> I don't give a f. I'll do whatever I think is right rather than optimizing myself over some study.

<comment><USER25> Do you believe the study to be methodologically flawed? Or just inapplicable to you specifically?

<comment><USER26> I believe it's not quite as simple or black and white as they say. Things generally don't fit into the help others or help yourself category so neatly in real life. Typically if you're in a team, the other team members will be doing things that impact you directly or soon will do.

And focusing on others vs self misses a more reasonable split: brief targeted help and more involved help.

Often in companies, people reinvent the wheel and struggle with problems with well established solutions - provided you can briefly give a pointer and do it with sufficient tact as to not offend then this kind of thing is almost always worth helping with.

</comment></comment></comment><comment><USER27> Sample size way too small to conclude anything meaningful.</comment>


Disqus launches new website - <AUTHOR> http://blog.disqus.com/post/56451685463/our-new-site-same-steak-more-sizzle

<comment><USER2> The new wibble-wobble of the bubbles distract me a lot. Ask yourself, "What is Disqus?"

Found by scrolling down:

"If you're passionate about writing and sharing, Disqus helps you build a community of active readers and commenters."

So...what is it? Compare that to the previous version that immediately placed it front and center: "We're a comment widget you can easily drop into any site."

I wonder if this will hurt their adoption numbers.

<comment><USER3> Occurred to us too. We're experimenting a bit with how we're communicating to our intended audience.

We've been testing signup rates and nothing alarming to note yet!

</comment></comment><comment><USER4> > How is everything now free? Disqus' business now centers around new > advertising built on top of content discovery.

I appreciate they needed a business model but when they launched this it was auto opt-in and enabled by default. I had dozens of clients email me complaining about 'weird ads' appearing on their sites, all mostly completely unrelated to what they had written or their site category etc (some of the clients who were female even complained about links to lad-mag style content, pictures of busty women etc, they were very offended). It felt like a really dirty trick and I have since migrated all Disqus installs to other solutions, mostly self-hosted comments. I would be very wary to trust them again given their history.

<comment><USER3> Sorry about that. We made some mistakes when rolling out from scratch and did some things that I'd be more careful about now. There was no malice intended and hope that you'll take another look in the future.

<comment><USER4> Thanks for responding, it is good to hear you recognised there were some mistakes and it has changed how you will do things going forward. I appreciate that you needed to explore revenue models and believe you when you say no malice was intended, I always thought of you as a good company. Unfortunately at the time I couldn't give definitive answers to my clients about if such a thing would occur again, so took the decision to just play it safe and remove Disqus. I will certainly reconsider Disqus again in future hearing these words from you however. Cheers.

Edit: oh and nice website redesign by the way!

</comment></comment></comment><comment><USER5> _As some close watchers of Disqus may already know, Disqus is now a fully free service. For everybody, for any site, of any size._

This is the bigger news. But which features from the paid were now made available to the free users? Analytics/SSO?

As an aside, Facebook, Google, and LiveFyre really, really dropped the ball with their own commenting systems. Disqus really takes the crown.

<comment><USER2> If they're offering it for free now, how are they making money to support their massive infrastructure? Are they selling personal information?

<comment><USER6> From the blog post: _Disqus' business now centers around new advertising built on top of content discovery. It's the way we bring more traffic to sites using Disqus and how we're also helping them make money from their communities._

[http://blog.disqus.com/post/56451685463/our-new-site-same- st...](http://blog.disqus.com/post/56451685463/our-new-site-same-steak-more- sizzle)</comment></comment></comment>


C++14 and SDL2: Managing Resources - <AUTHOR> http://ericscottbarr.com/blog/2014/04/c-plus-plus-14-and-sdl2-managing-resources/ <comment><USER2> This article starts with a flawed premise, that the right way to create a managed pointer is something like this[1].

        std::unique_ptr<void,void(*)(void*)> big_ptr(malloc(1), free);

The wasteful thing about this is that you have to store the deleter (free() in this case) right next to your void* for _every_ pointer you manage, so the unique_ptr is twice as large as it needs to be. What you'd like to do is store the deleter in the type of the pointer rather than the pointer itself. It turns out unique_ptr can handle this. If the second template parameter is a type with an overloaded function call operator, then unique_ptr will use that to delete. We can wrap it up like so.

        template <class T, void F(T *)> struct unique {
            struct deleter { void operator()(T *p) { F(p); }; };
            typedef std::unique_ptr<T, deleter> ptr;
        };

With this helper type you can now declare a similar managed pointer

        unique<void, free>::ptr small_ptr(malloc(1));

but this time notice that the deleter function is the second template parameter and not an argument to the constructor and the following holds.

        assert(2 * sizeof(small_ptr) == sizeof(big_ptr));

[1] I used malloc() and free() so those of you following along at home can easily try this out for yourselves.

<comment><USER3> > The wasteful thing about this is that you have to store the deleter (free() > in this case) right next to your void* for every pointer you manage

In the examples given, the function pointers in question would be stored on the stack. How many windows should an application be juggling at once that an extra 8 bytes per window is a concern? This seems like a premature optimization to me.

If you're individually rendering blades of grass in a goat simulator, sure. But by the time you're dealing with arbitrary-length application-defined strings (like window names), an extra pointer isn't a big deal.

For me to believe that a small_ptr was worthwhile here, I would have to see some benchmarks, which is how good optimization happens anyway.

</comment></comment><comment><USER4> This is a clever use of unique_ptr, but I can't help but think this is missing the forest through the trees. There's a lot of difficult to read code so you can use a C library resource with a bunch of C APIs. If you wrap the window in a class you can get simple RAII semantics, and add a friendly more C++ API.

What if you want to add event handlers for window events, change the window title, or even (gasp) throw exceptions instead of constantly check return codes? Wrapping the resource in a class gives you a great place to add this functionality. Without the class you have a nice resource that won't leak but still feels like you're programming C.

<comment><USER5> If you were creating a C++ wrapper, you still might prefer to use this same technique. Make the unique_ptr-wrapped resource a member of the wrapper instead of the raw resource. That would give the wrapper the same semantics as unique_ptr without any extra work. If you wanted shared ownership, use shared_ptr instead. Lastly, you wouldn't need to manually declare a destructor to free the resource.

In the end, I find it more readable to see unique_ptr and shared_ptr than raw resources. They describe more than just resource management.

</comment></comment><comment><USER6> Wouldn't it be simpler to just wrap the SDL_Window C object in a C++ class? That seems like a lot of boilerplate to just save oneself a destructor call.

Also, I'm not usually one to bash C++ for its syntax (I've written quite a lot of C++ in my days and still use it from time to time) but my god I find that template spaghetti code physically painful to read.

<comment><USER7> The point of this is you can write it once and use it for every type rather than having to write a wrapper for each one.

<comment><USER6> If I understand correctly you still have to write something like

        template<typename... Arguments> auto make_window(Arguments&&... args)
        {
            return detail::make_resource(SDL_CreateWindow, SDL_DestroyWindow, std::forward<Arguments>(args)...);
        }

for each resource.

Quite honestly at that point I'd sooner use a good old variadic macro, C99 style. I mean, sure, it's arguably less "elegant" and C++-ish but it'll be easier to understand, to maintain and won't spam me with pages of arcane template errors when I forget a colon somewhere, so it'll be easier to debug as well.

That's the double edged sword of the C++ template system I suppose, in order to gain in purity they lost the simplicity of the C macro system without gaining the expressiveness and convenience of the Lisp macro system. In the end, what percentage of C++ coders use templates outside of the STL you think?

<comment><USER8> The C++ template will give you extra type checking that the varadic macro won't, which is worth the tradeoff for the obscure error messages for me.

(At least the errors have got slightly better in recent g++ releases with colourised error output.)

</comment></comment></comment></comment><comment><USER9> My god. That's a hideous amount of hard to read code to support such a simple operation. Do not like. At all. (And I write C++ video game code all day every day)

<comment><USER10> This is meant as library code, not application code, though for template work, this is actually quite lightweight. You'd see scarier creatures than this if you write C++ libraries. Perhaps you should take a look at the implementation of your standard libraries or your favourite boost library sometime.

Let's break it down:

If this _weren 't_ library code you mightn't care about proper forwarding (which isn't important anyway since the function you're calling is written in C and C doesn't have lvalue-references!! - unnecessary complexity), so you would sloppily write this as:

        template<typename Creator, typename Destructor, typename... Arguments>
        auto make_resource(Creator c, Destructor d, Arguments&&... args)
        {
            typedef decltype(*c(args...)) ResourceType;
            return std::unique_ptr<ResourceType, void(*)(ResourceType*)>(c(args...), d);
        }

Which is much easier to understand, yes? Your standard passing multiple arguments along thing like you'd normally do when writing a custom printf.

Actually, now that I've had time to think about it, you can simpify the original code:

        template<typename Creator, typename Destructor, typename... Arguments>
        auto make_resource(Creator c, Destructor d, Arguments&&... args)
        {
            auto r = c(std::forward<Arguments>(args...));
            typedef typename std::decay<decltype(*r)>::type ResourceType;
            return std::unique_ptr<ResourceType, void(*)(ResourceType*)>(r, d);
        }

And again, written sloppily:

        template<typename Creator, typename Destructor, typename... Arguments>
        auto make_resource(Creator c, Destructor d, Arguments&&... args)
        {
            auto r = c(args...);
            typedef decltype(*r) ResourceType;
            return std::unique_ptr<ResourceType, void(*)(ResourceType*)>(r, d);
        }

Or, if you don't mind repetition of ResourceType:

        template<typename Creator, typename Destructor, typename... Arguments>
        auto make_resource(Creator c, Destructor d, Arguments&&... args)
        {
            auto r = c(args...);
            return std::unique_ptr<decltype(*r), void(*)(decltype(r))>(r, d);
        }

Clearer?

<comment><USER11> The standard dictates that decltype(*r) deduces to T&, not T. The std::decay is there to collapse the reference type into a value type. Therefore your simplification results in a compilation error.

An alternative way to get the value type is to use std::remove_pointer_t:

        using ResourceType = std::remove_pointer_t<decltype(c(args...))>;

</comment></comment></comment><comment><USER12> unique_ptr is not really a good solution to this problem. Something like Boost.ScopeExit for short lived resources, or shared_ptr (which stores the deleter using type erasure, meaning you don't need to allow evidence of the deleter to to permeate through your codebase) is a lot easier on the eyes...

        template <typename... Args> inline
        std::shared_ptr<SDL_Window> CreateWindow (Args&&... args) {
            return std::shared_ptr<SDL_Window> {SDL_CreateWindow(std::forward<Args>(args...)),
                                                &SDL_DestroyWindow};
        }

        auto window = CreateWindow ("App Name", SDL_WINDOWPOS_UNDEFINED,
                                    SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);

You know, or someone should write a good quality wrapper like you would just expect for _any_ other language (Python, Ruby, whatever). Many here seem to be blasting C++ when nobody is doing any better without a similar level amount of work elsewhere.

<comment><USER13> 'shared_ptr' can use type erasure because it is a much heavier object. 'unique_ptr' on the other hand is supposed to be a nearly free.

If you wanted a version of your code with unique_ptr, you would create a SDLDelete struct template. The result would be nearly identical except for an additional type parameter (and the new struct).

Then if you wanted to make "CreateWindow" generic for any of SDL's create/delete pairs... you are basically looking at the OP's make_resource code but slightly different. :P Their version just avoids making a new struct.

</comment></comment><comment><USER14> I can barely imagine a more fitting love sonnet for good old (modern) C99/11\. My eyes, dear $deity my eyes. I'm sure OP is a fantastic(ally) smart dev but I'm kind of glad I don't have to work with that.

<comment><USER15> This is no worse than anything else in the standard library. Writing generic template code is always ugly but once written you don't have to deal with the ugliness to use the resulting functions. It's not worth the complexity in most cases but if it's something general you're going to use a lot (and lots of C libraries have this idiom of Resource_Init Resource_Destroy function pairs) then it can be worthwhile.

Eigen is a quintessential example. It's some of the most complex and inscrutable template code out there but it makes writing numerical code in C++ almost as nice as matlab while also being extremely fast.

</comment></comment><comment><USER16> My own way of doing this:

[https://github.com/swarminglogic/sdl2-cross/blob/master/src/...](https://github.com/swarminglogic/sdl2-cross/blob/master/src/util/RAIIhelper.h)

[https://github.com/swarminglogic/sdl2-cross/blob/master/src/...](https://github.com/swarminglogic/sdl2-cross/blob/master/src/util/SDL.h)

Certainly less verbose, and solves the problem quite nicely as far as I've been using it. If someone with some wisdom feel like commenting on it, I'm not averse to learning.

</comment><comment><USER17> Wrapper classes + RAII is superior to this approach:

1\. Easier to read

2\. Easier to use

3\. Doesn't rely on bleeding-edge compiler features

I used to do some fun stuff with templates back in the day (CRTP), but I had trouble reading this.

Usually, the number of discrete resources you have to wrap this way is fairly small. I tend to cheat and write header-only libraries because the classes are tiny, don't change much, and shouldn't be used in every compilation unit if you have any semblance of a decent architecture.

Edit: clarified that I mean wrapper classes due to nerd sniping

<comment><USER18> > RAII is superior to this approach:

unique_ptr is not RAII now?

> 1\. Easier to read

That's debatable, here ``make_resource`` has to be understood once and will thereafter work with any C constructor/destructor pair. Considering the tone of your comment I guess you mean wrapping each pair in its own object so each of these wrapper objects (and its ownership semantics) has to be understood, and at a fundamental level they're redundant with unique_ptr.

If you don't like the generic thingy and want one wrapper object per call pair, you can just typedef the unique_ptr.

> 2\. Easier to use

Easier to use than calling a function and having a unique_ptr with clear ownership semantics?

<comment><USER17> Don't appreciate your tone. Relax buddy, it's Friday.

I'm arguing for introducing thin abstractions over the underlying API to handle lifetime issues, and encapsulate icky, SDL-specific details and types as they arise.

They are definitely redundant with unique_ptr. In return, they're higher-level and more abstract. It's up to the developer to select what level they need to be at. I favor abstraction and readability, others may not.

<comment><USER18> > Don't appreciate your tone. Relax buddy, it's Friday.

Wow, sorry, I didn't know you were an _internet badass_ , that changes everything.

As for relaxing, have you considered taking your own advice?

> I'm arguing for introducing thin abstractions over the underlying API to > handle lifetime issues, and encapsulate icky, SDL-specific details and types > as they arise.

Yes, now that you point it out I can certainly see a careful balancing of the tradeoffs between having to maintain custom code versus the ability to create more extended abstractions in your summary declaration that unique_ptr is hard to read, hard to use and not RAII.

<comment><USER19> The comment you responded to was indeed inappropriately irritating. But please don't respond to incivility with more incivility on HN. It's hard not to, but it only makes things worse.</comment></comment></comment></comment></comment>


The Largest Export of Every Country in the World - <AUTHOR> http://thesoundingline.com/the-top-export-of-every-country-in-the-world/ <comment><USER2> Such a nice map! I was surprised that for Sweden and Belarus the biggest export was fuel as the countries are not known for fossil fuel reserves. But they export a lot of refined petroleum products from oil they got from Norway and Russia.

</comment><comment><USER3> Blogspam of

[http://www.visualcapitalist.com/giant-map-top-export- every-c...](http://www.visualcapitalist.com/giant-map-top-export-every- country/)</comment>