Why the MacBook Pro Is Limited to 16GB of RAM - <AUTHOR> https://macdaddy.io/macbook-pro-limited-16gb-ram/ <comment><USER2> Come on, are we really blaming the RAM for battery life? Apple chose to put a much smaller battery in this model (75 watt) compared to last year (100 watt) for the purpose of thinness.

Find me a single review that laments the thickness and bulkiness of the 2015 model.

This is plain and simple industrial design gone amuck. Apple has beautiful hardware, but day to day use is important too (performance, ram, battery). Shaving millimeters and ounces hits the point of diminishing returns, especially when you focus on it to the exclusion of all else.

<comment><USER3> The claim that the new macbook will have issues with day to day performance is insane.

I run a browser with 20 tabs, linux VM in the background, and webpack and gulp in the background. I do all this on 8GB ram on a macbook from 2012 and it runs fast and smoothly, even with up to 4 hours of battery life. I can't imagine the new one would be _less_ performant in any way.

It's completely understandable that now they can optimize for other things, since performance is generally a nonissue now.

Apple is not blaming anything. They've _designed_ a computer for a purpose instead of pumping specs and numbers to gratify a bunch of vocal geeks. I'd rather much trust in Apple's design than a collaboratively designed PC by technical dilettantes with maximum performance everything. It's not just a about specs, especially in a laptop. Versatility, weight, battery, ease of use. These all come into play aside from raw technical component power.

<comment><USER4> > The claim that the new macbook will have issues with day to day performance > is insane. > I run a browser [...]

Building a single config & platform - with no other significant processes running - will cause OOM crashes on 12GB CI boxes with swap files enabled, when 4-5x 4GB linker process spin up in parallel when building my projects. This is my bread and butter, and it's still way too slow for my tastes on a 16GB box that isn't swapping excessively, which is the new MBP's _maximum_ "give Apple all my money" spec.

Your day to day works on it? Great. Mine hasn't for around a year at least, nevermind next year's. I could theoretically use it as a dedicated docs machine, or as a dumb terminal to an actually decent machine... or I could buy a quad-core laptop with twice the RAM - throw in an extra 4K monitor for good measure - and _still_ end up paying less than a MBP configured with half the cores and down 0.6Ghz in speed.

> It's not just a about specs, especially in a laptop. Versatility, weight, > battery, ease of use.

MBP's max specs aren't enough to handle my workload. MBP's 8GB models may not even handle Chrome, if the people bellow are to be believed. That's not "versatile". Weight is just another spec - 33% (~1.5lbs) lighter than the laptop I'm comparing against is nice, but not "who cares about any of the other spec" nice. Battery? More specs! Battery wattage just went down, as pointed out in the post you're replying to. Ease of use - finally something squishy and subjective! ...I'll prefer the numpad over the touch bar. Perhaps, on that front, I'm a weirdo.

But hey, if it works for your specific case, and you like 'em, enjoy!

<comment><USER3> Whatever you're using it for, clearly it's the 1%. Expecting Apple to completely gimp the macbook for the average pro user (dev, photoshop, video editing) to satisfy your computing needs is unreasonable. They can't cover all use cases, but they can cover most.

For your use case I recommend buying a spec'd up PC, such as a gaming laptop or desktop replacement laptop.

<comment><USER5> > Whatever you're using it for, clearly it's the 1%

Dude, are you seriously suggesting a laptop marketed for developers not be used by people writing and compiling code?

Seriously any project of decent size written in a systems language just consumes all the ram you can throw at. If you think this only happens to 1% of the developers, you need to step out of your echo chamber and see what other developers are doing.

<comment><USER6> _Dude, are you seriously suggesting a laptop marketed for developers not be used by people writing and compiling code?_

I know right - it's like everyone has forgotten that Pro means "for professionals". And also forgot that the booming sales of the iPhone and iPad owe everything to the ecosystem of apps and content created on Macs.

People doing 3D, engineering simulations, computational bio and chem, financial modelling, yadda yadda, there are loads of people who can make use of every byte of RAM and every core for Real Work. So some guy can make websites adequately on a smaller machine - he or she needs to look up and realize that that's a tiny corner of what computing is about...

<comment><USER7> Nobody for whom absolute CPU power is paramount is crunching on a laptop anyway. The sorts of examples you cite are better off implemented on a grunty workstation or even cloud computing. If portable access is needed, remoting in is the answer.

<comment><USER6> For many people these days their laptop is their only computer and they value the ability to work without cheap, fast connectivity, while traveling say. You know, the entire use case for portable computers existing _at all_.

<comment><USER7> You don't need to "own" a workstation to take advantage of cloud processing. It's the cloud. You rent the CPU cycles when you need them. And they can even be crunching away on your most difficult engineering simulations while you're mid-flight.

The number of people on this planet who _need_ to have 16+ cores of CPU power _on the tray table_ of an aeroplane could probably be counted in single digits.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Alright, it's time to make a confession: my "laptop" is actually just a desktop. It's plugged in 90% of the time and the other 10% is composed of 9% of time spent under 2 hours away from the plug and the last 1% is sitting in an airplane pretending I can get work done.

Does this sound familiar for anyone else?

Give me the 32GB memory and an extra few mm of thickness. I'll just keep it plugged in and not notice the difference.

<comment><USER9> It's really the "Macbook Air Pro" imo.

Portable and powerful is PERFECT for digital nomads and business travellers. A portable powerhouse that can be thrown in a day bag and taken to cafe's, coworking spaces, lugged through airports and around new cities.

But that's not the "Pro Market"

Apple should have released this iteration as the new Macbook Air or dropped the Air and called it a "Macbook". Nobody would have complained.

Then, released a new lineup of Macbook Pros around the same size as the previous generation and dropped quad core processor in the 13" model. Maybe even squeeze in a discrete GPU like the new GTX 1060 or GTX 1080. Nobody would have complained then.

<comment><USER10> >But that's not the "Pro Market"

Every time I come into a thread about the new MacBook Pro, I'm always being told that I'm apparently not a professional. And it kinda hurts a little bit.

Maybe it doesn't meet your particular needs, but insulting everyone who doesn't use 32GB+ of RAM on a day to day basis isn't very nice. Yes, saying "you're not a professional" is an insult to people who are very much professionals.

If you guys want a machine with multiple processors and 128GB of RAM and 5TB disk storage with terribly battery life, you should pressure Apple for a new desktop. The MacBook Pro is not and never has been a mobile workstation. It's a notebook first and foremost.

<comment><USER9> First of all, i'm pretty sure the Macbook Pro has always been a mobile workstation (and their only computer) for 10s of millions of people since it was released.

Second of all, This isn't about you. nobody is saying you're not a professional because this new Macbook suits your needs. It's about the branding.

The whole "Heres our affordable, portable consumer laptops" and "Here's our more powerful pro laptops" defined the brands. The "macbook/air" and "macbook pro" were branded for two different groups of users.

Now what's happened is Apple combined them into the one machine and our preconceptions of those brands have been shattered.

Many including myself have been holding out for years for a portable Apple computer (13") that can be a workhorse (Quad core) and by making the pro thin and light it's meant that's no longer possible. It should have just been a Macbook. Hence my previous post about keeping them segregated into two machines.

<comment><USER10> But that's wrong. All of that is wrong. Literally throughout Apple's entire history, everything you just said has been completely false.

Let's start with "they've combined them into one machine". Then why do the 12" and the Air exist? _Those_ are the "consumer" devices. If what you're saying is true, the MacBook Pro and the 12" MacBook are the same machine. That's not true at all, there is a substantial difference.

And then let's tackle "the MacBook Pro has always been a mobile workstation". Which again, is completely not true. It's always been _exactly the opposite_ of that. What I have sitting on my desk behind me is a mobile workstation. It's a Thinkpad W530. Go ahead and look up the specs, you'll see what I mean. 32GB of RAM, a quad core i7, a massive screen, and it weighs about three hundred pounds. It also gets 4 hours of battery life, and that's _with_ the extended battery sticking out of the back. A MacBook has never been a mobile workstation. It's always been a notebook that's been as portable and battery- efficient as technology has allowed, while also being able to easily run the tools that most professionals require. Not once has Apple ever said "Pixar ditched their rendering farm for a single 13" MacBook Pro!"

I'm sorry if your preconceptions of the brand have been shattered. I'm also sorry to say that your preconceptions have always been wrong. You're upset because Apple didn't make a device that you were waiting for, but they've never made that device. So maybe instead of complaining that "the new MacBook Pro isn't made for professionals!" you can understand that your definition of professional doesn't necessarily line up with Apple's. It never has.

</comment></comment></comment></comment></comment><comment><USER11> I don't understand the imperatives to make the machine thinner and increase battery life.

I would have paid for a 32 or even 64 GB model, but instead I'm going to delay my upgrade for 6-8 months so that I can see if something better than the new MBP comes along.

I am of the opinion that a Pro machine does not need to be the thinnest available model.

<comment><USER12> Because it's a MacBook; with batteries in it. The value is in the mobility. If you don't need the batteries and mobility, you could buy a Mac Mini, iMac or Mac Pro.

<comment><USER11> But they didn't upgrade the Mini, iMac, or Mac Pro. The Mac Pro has been the current model for at least two years. The iMac is a hack that uses two logical display panels to produce the 5K resolution, because there isn't enough bandwidth for a single one. The Mini is nearing the 3 generations old mark.

<comment><USER13> Why even mention the way the iMac display works? Using the machine you would never know and its a very nice computer. The complaints about the mini and pro are legit but there is barely anything to complain about with the iMac.

<comment><USER14> It will matter once Apple decides to drop support for the current iMac. (Who knows, maybe the ARM switch will eventually happen? The G5 iMacs became obsolete over night when the Intel switch happened.)

As it stands, you can neither recycle it as an external display nor can you run Linux on it at full resolution.

Not really a "pro" complaint - just something to keep in mind if you plan to hand it on.

</comment></comment></comment></comment></comment><comment><USER15> Since the latest release, I've found that mentally substituting "Deluxe" for "Pro" helps to clarify Apple's design choices. I just can't see how a machine without USB non-C or display ports can be meant for professionals. I'd gladly pay for a heavier, thicker machine to have those things (and to avoid the dongles).

<comment><USER16> Exactly. There's nothing "Pro" about it. Maybe "Executive" or "Limited".

<comment><USER17> Maybe this is all the natural progression towards the final marketing scheme. Eg. The automotive industry.

Did you want the DLX, GS, or GX trim package?

Obvious extreme sarcasm here. But it seems to be the trend.

</comment></comment></comment><comment><USER18> _The Intel chipset being used supports the following kinds of RAM: DDR3 RAM, Low Power DDR3 RAM (LPDDR), and DDR4 RAM. However, LPDDR3 only goes up to 1600 megahertz in speed, but Apple uses 1866Mhz RAM. How is this possible? That is because there yet another RAM standard, known as LPDDR3E (E for enhanced) RAM, that does go up to 1866Mhz.

LPDDR4 is not supported by Intel's CPU, and the DDR4L (another low voltage RAM type) standard is not finished yet. So desktop class memory (plainly spoken DDR4) would be the only option if they wanted to go past 16GB._

I don't follow the argument here. Why not just put another 16GB of LPDDR3E on the board?

<comment><USER19> AIUI Intel's non-Xeon chipsets won't go over 16GB for DDR3 in most cases.

<comment><USER20> Does Apple not have enough pull to get that already-existing feature on the chips they're buying?

My ivy bridge laptop supports 32GB of DDR3, for what it's worth.

<comment><USER19> I would guess that it would require more than one vendor, even one as large as Apple, to request it aggressively earlier in the dev process for something like that to get done, because of the amounts of QA required.

I would further guess that 4 DIMMs, more than just memory controller support, might have required too much precious board space - which, when combined with the power requirements and additional feature enhancement requirements for Intel, might have made it a nonstarter.

</comment></comment></comment></comment><comment><USER21> I'm sure they've focus grouped this to death. Everyone wants battery life. It differentiates the product and sells computers.

Many people claim to need >16GB, but many of those folks really don't. The folks who need to run VMs (the biggest group, IMO) have workarounds.

The folks left are a small number and have alternatives, mostly in the cloud. And they make the Mac Pro to address those folks, although obviously that's a flawed product as well.

<comment><USER22> I know quite a few people who require >16GB, and not one of them is a power user nor do they use a VM. What they do is edit large amounts of 4K video in FCP, and they're rather screwed without an actual MacBook Pro.

No, there are no cloud options for them, they need the RAM for the video. No, the Mac Pro isn't a viable option for them at that price, nor is it portable.

I'm pretty sure they don't give a damn about battery life, either. They do their editing at a desk, and then take the MBP with them.

So, for now, they're stuck with old models until there's a better one, or they spend a fair amount of money building a new pipeline and purchasing new software.

<comment><USER23> What old models? As far as I know there aren't any older MacBooks that support more than 16GB of RAM either.

If you're going to compare to desktops, start with the iMac, which is "only" a year old at this point, unlike the Mac Pro which is several :(. The iMac with 5K display starts at $1,800 and is configurable to 32GB RAM, while the MacBook Pro 15" starts at $2,400, and then you probably want an external display too. (That doesn't include the rather high price of actually configuring the iMac for 32GB, but its RAM is [still] user-upgradeable, so better to buy it somewhere else.) Actually, considering that the Mac Pro starts at $3,000, which is not that much more than $2,400, I'm not sure why you think the price puts it out of range...

But I definitely understand why you'd want it in a laptop.

<comment><USER24> Well, the 32GB MBP price is "unknown", but the Mac Pro at 32GB is $3,500, not $3,000.

</comment></comment></comment></comment><comment><USER25> This is why I built a hackintosh last week. 64GB, 4.5ghz OC, 6GB CPU. I'll keep trudging along with my 2012 MBP when I travel, but considering I work from home 80% of the time it was more important to optimize that time.

FWIW, building one is far easier than it used to be. Everything is working great, took me about an afternoon to get it there. Watching Photoshop open as quickly as Sublime text will never get boring.

Edit: This is my build if anyone is interested, [http://pcpartpicker.com/list/gwV6qk](http://pcpartpicker.com/list/gwV6qk)

<comment><USER26> How is Xcode support nowadays? I got a Hackintosh VM working circa 2013 but had a lot of problems getting the latest version of Xcode to function at all.

<comment><USER25> No problem here, though I haven't submitted anything to the store, but I can't imagine its an issue.

The only thing that isn't working is handoff, but you can get a card that enables that.

</comment></comment></comment><comment><USER27> The market forces around laptops would seem to be a ripe area for serious academic study. I honestly can't find a laptop I _want_ to buy only ones I weigh silly trade-offs. (to be fair: my biggest complaint is around the lack of keyboard choices). It seems that the market desires either can't drive laptop options, or the market is vastly different than I perceive. For example: Why did it take so long for 720 screens to die as an option? For $50 more you get a 1080. I watched this for 6 years (2009 to 2014) and really can't fathom it.

Now... this is for Windows based machines, and I'm sure the forces are different for Apple, but it would be lovely to read a serious study on this. I suspect there is something along the lines of cost and supply chain factors dominating the "refresh cycle" but this used to be handled by different product lines with wildly different configurations. (it still kinda is... Alienware vs Inspiron vs Yoga vs T vs P series but Apple seems to buck this trend completely) Anyway... I just need the cathartic release of posting (venting) with these laptop articles.

<comment><USER28> My theory behind this is that the most efficient functioning market needs intelligent buyers and sellers. The buyers have to be able to discern what the specs mean, what the quality of the parts are, what the expected lifetime is, and with computers not only that, but they have to be able to evaluate the software options (Windows vs OS X, malware subsidized laptops versus not)? Even explaining malware to a layman is difficult.

So you had the two markets, business and professional consumers who knew what they were buying, and then regular consumers who mostly cared about price but are also swayed by large numbers (more GB, more HZ, bigger screen, more software a.k.a. malware).

Then I think the tide sort of turned in the past decade where even the common populace had realized Windows consumer laptops were full of crap that caused it to run slow and unexpectedly and people noticed Apple's laptops were more consistent with user experience (which they were), so now Apple has a reputation of being the no nonsense brand (which they deserve). Of course, now Apple can also charge a premium for this so you see people with disposable income sticking to Apple's ecosystem, and then the rest of the OEMs fight for price conscious consumers and getting barely any profit out of it.

Obviously for Apple, keeping things simple keeps their operating costs down, so they don't need to cater to every purchaser, and they probably decided that now they're the default brand to purchase if you have the money, they don't need to waste resources chasing after a small segment of the market looking for extremely high specifications.

</comment></comment><comment><USER29> I wonder if it would be possible to design a system which would power down some of the memory when not plugged to a power source. I do all my dev on an MBP and would be more or less fine if the memory-intensive things were only available when plugged in. That said, I don't really feel like 16gb limits me in any way except for doing data processing, but that should be happening on the cluster anyways.

<comment><USER30> Possible but hard because:

1\. OSs are generally unaware of the details of memory controller configuration, everything is preconfigured by firmware. Apple's vertical integration could help here, but they would probably need help from Intel and it would work only in OSX.

2\. It's not the case that if you install four 8GB sticks they will be mapped at 0-8G, 8-16G, etc. and the OS can simply move data from one area to another. For performance, data are striped RAID0-style across all modules. They would have to disable this.

3\. I don't know if OSX supports non-identity VM-mapping of kernel memory pages. Linux for example doesn't afaik. Without this it's impossible to move arbitrary kernel objects because you can't find and update all pointers pointing to them.

</comment></comment><comment><USER31> Great writeup and detail. However:

> Even if it weighed 10 kilos and cost $10k I would still buy it.

> (To show you exactly what I mean in terms of personal needs, I recently > rendered a music video in HD using a neural net called Style app. Due to the > 16GB RAM limitation it took several days and wrote 20.44 Terabytes to my > drive in swap space (yes, over 20,000 gigabytes). This would have been an > order of magnitude faster on a system with 32GB of RAM).

If your rendering video and can afford a $10k computer, then you should be using a Mac Pro. You can get a 2.7GHz 12-core with 30MB of L3 cache and 64GB of memory for around 8.5k.

<comment><USER32> Why not rent a supercomputer on the cloud just for the time of such an experiment?

I rent a 16 core/128GB machine at a cloud provider. I use it for heavy database treatments. And my laptop merely became a tmux terminal ever since.

<comment><USER31> I don't know of a cloud provider that rents OS X machines do you? OS X is needed for Final Cut Pro, etc. If you're using Adobe Premier then you could use Microsoft Azure or another cloud provider that supports Windows.

<comment><USER33> Depends on how the workload is split and such. Using AWS for video encoding is actually quite viable as long as Amazon don't charge for incoming bandwidth and dirt cheap spot instances could be found at the right time of the day.

<comment><USER34> Cloud render farms have been a thing in CGI for nearly a decade now. It can - sometimes - be cheaper to buy time than to buy hardware.

But there are a lot of disadvantages. The process only really works for final renders. All the creative work needs to be fast and local, but thumbnail renders don't always give you enough detail to make good decisions.

It doesn't work for audio, because audio isn't great with low-quality previews and often needs hands-on changes.

It doesn't work for many kinds of ML - not unless the render machine has the latest graphics cards.

It doesn't work for renders with huge asset libraries spread around a LAN.

And so on. Basically there is a list of use cases, but it's not even half of all possible use cases.

Meanwhile dual-Xeon servers have really started to kick ass. These are workstation grade machines with high four and low five figure prices. You can have up to 48 independent cores on a dual-CPU board, which is excellent for video rendering.

Or you can get a blade rack. Depending the project, they can be better value than an off-prem cloud account. (Sometimes).

Apple has turned its back on this space. I don't entirely understand why. Xserve had real potential, but they decided to go dumbed-down consumer instead.

<comment><USER31> In terms of Xserve, I think it made sense to drop it. If you're buying a server, nearly all applications make more sense using Linux and commodity hardware. The exception are desktop based (GUI) applications which Mac Pro targets. There really is no viable market for a Mac Server.

</comment></comment></comment></comment></comment></comment><comment> mark-r So the blame is on Intel, not Apple. What does it matter? Apple is a big enough customer of Intel's that their needs should have been accommodated in the chip requirements before they were designed. Either way it makes no difference to the pro customers who need >16GB.

<comment><USER3> Of course the computer can always be improved. But the point is Apple is improved it the best they can, and certainly better than any competing manufacturer.

<comment><USER35> Competing laptop manufacturers have options for more ram.

<comment><USER36> >> Competing laptop manufacturers have options for more ram.

And not just for 32GB, many mobile workstation makers offer up to 64GB. You can also get ECC and mobile Xeons too.

</comment></comment></comment></comment><comment><USER37> The weird thing is that Apple did not use all the space they possibly could for the battery. Have a look at the teardowns. There is room to put ca. 5% more battery. Supposedly they wanted to stay below 3 pounds.

That is the amount the other RAM type would have used... So this was likely more about weight than battery life.

</comment><comment><USER38> I wish Apple would do a portable computer without a battery. I work on power 99% of the time, and would love e.g. A portable iMac.

<comment><USER39> Isn't that the mac mini?

<comment><USER2> Apple should actually make a mac mini (again)

<comment><USER39> The apple store still has them for sale, they just haven't been upgraded for a couple of years.

</comment></comment></comment></comment><comment><USER40> The real why is: Because we say so, you will buy it anyway.

Its cheaper(no slot) and easier(same production line) to manufacture, and as a bonus forces users to upgrade earlier, not to mention planned obsolescence. Same goes for the SSD.

Anybody want to guess how an official Apple data recovery procedure looks like in case of soldered SSD and no cloud backup? I can tell you how - there isnt one, just like with phones.

</comment><comment><USER41> >"However, LPDDR3 only goes up to 1600 megahertz in speed, but Apple uses 1866Mhz RAM. How is this possible? That is because there yet another RAM standard, known as LPDDR3E (E for enhanced) RAM, that does go up to 1866Mhz."

Why does apple claim 2133Mhz?

<comment><USER42> Probably because its single channel. They bump voltage and freq to catch up in performance.

If they would choose 2x16 and lower freq, voltage resulting performance would be even better with similar power usage.

Apple prefer to make more money. They use power of brand to sell overpriced products to clueless crowd. Just go apple store to see audience, most people there do not even know what is RAM.

[1] [http://nucblog.net/2015/09/dual-channel-vs-single-channel- do...](http://nucblog.net/2015/09/dual-channel-vs-single-channel-does-it- matter/)

</comment></comment><comment><USER43> What I find interesting in this PRO debate is that most +16GB users don't even use Apple, but brands like Dell, HP, Siemens and others.

Apple is not stupid. They know the market. And imho the anger here on HN is mostly HN bias.

<comment><USER44> Not sure I agree with you. I'm here because I'm moving into the tech world but I'm coming from a background in photography.

Nearly all my friends in that world (me included) use topped out MacBooks for portable stuff and the video folks are using Mac Pros or hackintosh's. They certainly need more RAM, I know at least two guys who would have killed for 64GB RAM in a Macbook for their 4k video work. And I could certainly use it to speed up batch operations of hundreds of images, or even to be able to basically use the laptop when pushing around several 24mp RAW images in photoshop or even use a single RAW edit on a 42mp file from a Sony A7r2 which utterly killed my current MacBook with 8GB RAM.

I see loads of retorts like 'just use a desktop for the heavy lifting stuff' but that's so ignorant of the requirements on some markets. Needing to edit on the go is essential for many creators, especially for location shoots, and not even particularly complex ones, so power in a portable package is absolutely essential to folks well outside the 'developer' or tech world.

No one I know is thinking about getting the new MacBook. Some are hoping for next years update but others who are running older models and need an upgrade now are now casting around for alternatives.

They may know their market, but their market might not be what we think it is. It may be their market is moving to be like their phone market with a significant portion buying the brand jewellery Apple carries.

So I guess I'm saying that there is a large segment of media creators (who are often suckers like me for the styling of the Apple laptops) who are now not seemingly part of Apple target market, and that might be bad for the wider Apple brand.

I'm not particularly beholden to any manufacturer and nor are most of my friends. They go where they need to to get the kit that lets them do their job. There's an elastic period where a few issues can be overlooked but for me and others coming from this creation world the limit has been reached.

<comment><USER43> But didn't the video world already switch to Dell over two years ago because Apple could not keep up with high res video editing?

I might be totaly wrong, but I think the real pro world doesn't look for a nice looking tool but for one that does the job. That's why I think +16GB users already use other brands.

</comment></comment></comment><comment><USER45> I kind of feel like Apple's design philosophy is off. It's not like the Oxo brand of having tools that are easy to use.

\- I still can't hold my iPhone 6 without it slipping out of my hand (and I even have a case) \- My Macbook Pro Unibody is very sleek but it just slides off my lap because the bottom surface is so smooth. \- Off-boarding useful connections like USB, HDMI, DisplayPort etc meaning you have to purchase and carry around a bunch of dongles for whatever tiny saving they get from the battery / footprint. \- The new Macbooks are, as always choosing sleekness over just making a laptop that is more powerful than they've made over the last 4 years. \- People are complaining about the trackpad in the new MBP not having space to rest their wrists.

etc etc

They seem to just be optimizing for design's sake and not really considering the use case of what people use the computers for. It's starting to be a great little sleek computer for an executive to put in their carry-on and less like a strong office computer that can do hard work (for me it's software engineering) and be good enough to USE ALL DAY.

</comment><comment><USER46> I would prefer a MacBook Pro that was 1" thicker, if only it had better cooling and kernel_task didn't go up to 3700% and freeze up all the time.

</comment><comment><USER47> Because of Apple's anorexia, that's why.

The 10-15% increase in battery consumption could have been easily solved by having a 10-15% bigger battery.

</comment><comment><USER48> Touch bar uses more power than ram.

<comment><USER49> Source?

</comment></comment><comment><USER50> I'm basically going to run my 2008 Mac Pro desktop until it completely seizes up. It's been constantly upgraded since then, and is still going strong. When the day comes, I'll have to make the decision on whether to continue with MacOS, because nothing is going to replace this anytime soon apparently.

</comment><comment><USER51> Be that as it may, I'd sacrifice some battery life to have the option of 32GB of RAM.

The moment you need to start running Windows VMs on top of OSX along with Visual Studio, SQL Server, etc., that 16GB limit becomes incredibly aggravating.

Battery life is an especially crappy excuse when you consider that most of the time I'm running on outlet power - it's very rare that I don't have access to a power point for 5 - 6 hours at a time.

And lest we forget, this is a machine called the MacBook _Pro_. Pro, as in, for the use of professionals. And professionals need more system RAM. Hello Apple, are you getting this?

I'd also like an option for a 2TB SSD and more (not less) ports, particularly USB, because I don't want to have to carry around a pile of dongles everywhere with me that all too easily become lost. Remember: the machine is called the MacBook PRO.

<comment><USER52> A lot of these fights seem to revolve around the word _Pro_. I'm a professional: I've worked with computers and software my whole life, and I am very good at it.

I don't think I'll particularly need 32GB of RAM or USB ports on my laptop. Does this mean I'm not a true professional? Real men need 32GB and USB?

That said, I'd probably opt for 32GB and a bit more weight.

There is a 2TB option, by the way.

<comment><USER51> That's a fair point and it wasn't my intent to start a "real men need X" style of discussion. Nevertheless, VMs, and particularly Windows VMs with VS and the rest - at least on the kind of systems I always seem to end up working with - are resource hungry. I'm not suggesting that 32GB is for everyone, but I'd at least like the option available knowing that I might be trading some battery life by selecting it.

(Worth knowing about the 2TB option - thanks for the tip. I refreshed last year when 1TB was the top end. Fortunately I think the drive is still user- upgradeable.)

</comment></comment></comment><comment><USER53> I am divided on this. I think we as the software industry have serious performance issues, maybe except for some legitimate use cases like number crunching, video editing etc.

I don't know of a non-trivial Rails app which uses less than a couple hundred MBs of RAM. We have a VM with a minimum RAM requirement of 8 GBs at work which runs a conglomerate of Rails APIs, which makes 16 GB a minimum on my laptop. The only reason the memory bloat/leak of a freelance Rails project I'm working on goes undetected is that Heroku restarts their dynos daily. For comparison, an Elixir/Phoenix app is using < 40 MB right now.

AFAIK base RAM requirements of many Java apps are even worse.

Opening Gmail in Chrome immediately eats 1 GB of RAM, vs. 60 MB for Apple Mail app. Many Electron apps like Slack, Atom and Spotify use hundreds of MBs to GBs of memory, vs. 150 MB for Sublime Text (5 MB for Vim!). And they are sluggish. As much as I love the open web (and I'm mostly a web/backend dev myself), I hate the fact that I often have to prefer native apps.

I'm seriously considering other laptops right now, but can't find a serious alternative, especially considering the fact that there are no Linux-rated laptops close to my location. And shoehorning Linux into Windows machines is pain, I tried that for ~1 years both at work and at home. The best non-Mac laptop candidate I'm considering right now has a long article written by someone describing how to install Linux on it, with some "slight" annoyances like a non-functioning webcam and a problematic wifi in the end. Windows? Nothing there comes even close to iTerm2 and oh-my-zsh combo (and many other tools, workflows etc). And I haven't even touched the subject of design.

None of this is heavy computing. I think we seriously need to consider slowing down this madness and try to improve. I'd normally love the 16 GB limitation so that we'd be somewhat forced to that direction but since there is no "kill the bloat!" initiative or something, we sadly need beefier machines for the short/mid term.

</comment><comment><USER54> Great article. However, good arguments have never convinced some people. I'm so tired of this hand-wringing over the amount of RAM in a computer. The entitlement of some people is ridiculous. Apple, unlike Microsoft, does not produce software and hardware products for software engineers. It's time for software engineers to accept that and move on. I have.

</comment><comment><USER55> 16MB may be enough for today for 95% of the users, but in 3 years when Apple is still selling this model it is going to be an issue, especially when you consider that those laptops sold 3 years from now will be expected to run for another 5 years or so.

</comment><comment><USER56> Too many factual errors in the article. Many of the comparisons state DDR3 - but DDR4 is not DDR3.

> the difference of power draw between DDR3 and DDR4 is almost negligible.

It's NOT. The article he's citing mentions IDLE standby power consumption. Not the same thing as active power consumption.

\- Correction: Power draw of DDR4 and LPDDR3 is very similar under active usage (i.e. not in standby). DDR4 might be possibly slightly lower.

I couldn't find a direct comparison, but according to Samsung:

      * LPDDR3 vs DDR3L uses 15% less power in operation [1]
      * DDR4 vs DDR3L uses 37% less power [2]

\- Correction: LPDDR3 is much more efficient for STANDBY (yes, you can have that 30 days standby). [3]

So without LPDDR3, in my opinion, the standby of MBP would be reduced to ~15 days from 30 days (haven't done proper calculations but it's roughly half). But it wouldn't matter in normal usage.

I still believe Apple didn't consider DDR4 due to size concerns as even SODIMM DDR4 on the logic board would larger.

[1]: [http://www.samsung.com/semiconductor/global/file/media/Samsu...](http://www.samsung.com/semiconductor/global/file/media/Samsung_Mobile_DRAM_2013_Final_HR-0.pdf)

[2]: [http://www.samsung.com/global/business/semiconductor/file/me...](http://www.samsung.com/global/business/semiconductor/file/media/DDR4_Brochure-0.pdf)

[3]: [https://www.micron.com/~/media/documents/products/product- fl...](https://www.micron.com/~/media/documents/products/product- flyer/why_dram_for_ultrathins_lo.pdf)

</comment><comment><USER57> I agree with many posters in this thread that Apple is taking "thin and light" to an extreme. I'd want other things than thinness and lightness, like being able to configure it with a 4TB spinning hard disc + a small SSD, configured as a Fusion Drive. This 4TB bus-powered hard disc [https://www.amazon.com/dp/B00ZTRXFBA/?tag=thewire06-20&linkC...](https://www.amazon.com/dp/B00ZTRXFBA/?tag=thewire06-20&linkCode=xm2&ascsubtag=WC24562) is only 0.8 inch thick, as opposed to the Macbook Pro's 0.6 inch thickness. I'd gladly take the additional 0.2 inch thickness for having lots of storage.

I'd also want it to have an upgradeable memory and storage.

SSDs are still unaffordable — the Macbook Pro with 2TB SSD costs more than $4000! While the aforementioned 4TB hard disc costs only $100.

</comment><comment><USER58> I don't mind 16GB of RAM, I get the job done with 8GB (2013 model) using (Chrome, Atom/Sublime, Xcode, Terminal, Spotify, External 4k monitor..), what I want is dedicated GPU and Quad Core CPU by default for a normal price.

</comment><comment><USER59> Apple are just victims of their own game - making stuff thinner/lighter every year as it's somehow the next world wonder. Unless they'll finally admit it and stop this BS, they'll get themselves cornered soon enough.

I mean just use the advantage of new technology to fill up the gained space with batteries. The premise of limiting RAM is also pretty much BS - if I get a device with 16GB RAM I still get the same battery life as now, but if I put more memory inside, I do this willingly to sacrifice battery. NOTHING CHANGES for people with 8/16GB configuration.

Unless they're doing this with the classic Apple smug "we know what's best for you" reason. Oh and to sell more adapters.

<comment><USER60> > I do this willingly to sacrifice battery. NOTHING CHANGES for people with > 8/16GB configuration.

Did you not read the article? Everyone would be affected because they would have to use a completely different RAM technology. Even for people with 8/16GB configurations.

<comment><USER61> It probably won't affect 8/16 GB people. Since the RAM are soldered, each config will be a different board, so they can keep existing 16GB config, and offer a 32GB config with DDR4 + required controllers, etc.

<comment><USER60> Oh, yeah, they should design and produce a completely different board that virtually nobody buys. That makes a lot of financial sense.

<comment><USER61> I agree with you that it doesn't make financial sense. Maybe Apple can simply state the demand isn't there for 32GB, or just don't respond at all.

Edit: Want to add that I think some people are not happy since they perceive the line between thin (Air/Macbook) and powerful (BMP) is being blurred and MBP is becoming too MacBook-like.

I am currently a 2014 MBP user. I love it, but my next laptop probably won't be a MBP. I don't own a desktop, and I am running out of storage. My next laptop will have upgradable storage that uses a standard part (M.2, etc), and the new MBP doesn't fit my need. I tend to keep my laptop for a few years, and lack of upgradability impacts me significantly.

</comment></comment></comment></comment></comment><comment><USER62> Lenovo T460p comes with quad core Intel 6th gen processors and up to 32 GB of DDR4 and claims up to 12 hours battery life on a 72 Wh battery. Why is it neglected in the comparison?

<comment><USER63> I'm not familiar with the ThinkPad T460, but the T560 has two batteries. If you need longer life, upgrading the second battery from 47WHr to 72WHr costs an extra £12.

</comment></comment><comment><USER64> On the other side the SSD is very fast (rumors say 2.2GB/s, that is not so far from DDR2) so at least swapping will be seamless...

</comment><comment><USER65> I would expect 64GB of RAM, and not 16. The MacBook Pro 2016 is supposed to be a powerful laptop, not a cheap netbook.

</comment><comment><USER66> Just curious relevant to this topic- who needs RAM over 16 GB in a thin, mid- range laptop whose processor ends with the letter "U"?

An advice for the multimedia pros- please stop whining about the RAM limitation of MBP 2016 and get a real workstation. a Mac pro (and some iMac) of any generation available in the market shall deliver several multiple of power that any MBP can do.

</comment><comment><USER67> The credibility of the whole story fell to the floor when he said that sleep mode would kill more batteries because they fail when completely discharged. Apple has had top notch battery protection for years. Totally draining a macbook battery to failure has not been possible for many years.

<comment><USER68> Continued deep discharge does however shorten the life of lithium ion batteries.

<comment><USER67> I'd really like to see a recent reference on how much. Given the discharge maintaining the batteries is very small and very manageable I highly doubt it is significant over any lesser depth with these lipo batteries manufactured specifically for Apple.

</comment></comment></comment><comment><USER69> The RAM thing is a myth. LinusTechTips, the YouTube channel, even did their own survey about it and the results are here: [https://www.youtube.com/watch?v=axZBbgfEZf0](https://www.youtube.com/watch?v=axZBbgfEZf0)

<comment><USER70> Have you read an article? It mentions LinusTechTips and explains what's wrong with their analysis.

</comment></comment><comment><USER71> I think this article misses the point that it seems many customers are disappointed they can't get more than 16gb and many would be willing to have the trade-off of 50% less battery life.

How many people work away from power for more than 5 hours at a single stretch?

<comment><USER72> This exactly. As a developer applications like docker and vagrant are part of my normal activities. The 16GB limit just does not work in this model. FWIW I was waiting on a laptop upgrade, and after seeing the new lineup from Apple I ordered a Linux laptop with 32GB of memory.

<comment><USER73> A major point of containerization is more efficient resource utilization, memory in particular.

How has it come to this?

<comment><USER74> To run the whole system need multiple VMs. It's not enough to just run the app container anymore. There are a bunch of support containers and if you want to experiment with failure then there are even more VMs & containers to run. sure we could just dump $1,000 into a cloud provider for a couple months usage, for me I'd rather put that $1,000 into my laptop (i7 3.8GHz, 64GB RAM, 2x SSD, 1x2TB HDD) and be able to experiment at my leisure. Plus it's quicker to iterate if the experiment is running all the time, cloud is expensive to run stuff that doesn't generate income.

<comment><USER75> What on earth laptop do you have with all that for $1000? Or maybe you mean $1000 in upgrades, but still... what laptop will take 64GB of ram and 4 disks?!

<comment><USER63> A ThinkPad P-series workstation takes four disk drives: two SSDs, one HD, and one DVD. It has four RAM slots so you can have 64GB. Low-end CPU is an Intel Core i7-6820HQ but you can upgrade to a Xeon.

It's a highly configurable, professional machine.

[http://shop.lenovo.com/gb/en/laptops/thinkpad/p-series/p70/](http://shop.lenovo.com/gb/en/laptops/thinkpad/p-series/p70/)

The Dell Precision M6800 (no longer available) supported a 4 drive configuration if one was a Mini Card plugged into a slot on the motherboard, It had three 2.5in drive bays. You could have a look at the current Dell models, or an HP Z Book.

</comment></comment></comment></comment></comment></comment><comment><USER76> I have a Mid 2015 15" rMBP w 16GB RAM. I'm actually worried about the SSD wear and that's why I would like to have 32GB RAM.

I'm quite okay with its performance but I routinely have ~4GB of memory swapped out, even though I'm trying hard to keep my browser tab count below 20.

I have 4-5 Clojure/ClojureScript projects open in IntelliJ; that eats ~1-2GB RAM.

For 3-4 of them I'm running a REPL; that's around ~1GB each, which is ~3-4GB in total.

Safari with 10-20 tabs; 1-2GB

Google Chrome Canary 4-5 tabs for the webapp under development (logged in with different type of users into different environments [dev/stg/prod]); ~300MB/tab => ~1-1.5GB total

Everyday utilities also add up to 1.5GB at least:

• Slack 0.4GB

• (sometimes Gitter 0.3GB)

• Spotify 0.3GB

• AirMail 0.3GB

• OneNote 0.2GB

• SublimeText 0.2GB

• iTerm 0.1GB

• 1Password 0.1GB

(and I don't even mention Box Sync or Dropbox or Google Drive or Ethereum or IPFS node because I usually keep them turned off while I'm coding...)

My kernel_task is usually round 1.5GB but sometimes grows up to 2+GB

So that's 2 + 4 + 3 + 1.5 + 1.5 + 1.5 = 13.5GB Then there is only 2.5GB left for disk cache and ~0.2GB memory is compressed at this point.

So that's the minimum memory requirement after a cold boot for _work_. Anything else I do start to force memory to be compressed then swapped out.

BUT THEN I also have a personal account for non-work related things which obviously forces swapping.

I have to say though I see very little stuttering or beach balling, though typing in IntelliJ can get jittery while it's indexing. I think macOS' memory management is quite good for desktop usage.

I do try Ubuntu/Fedora from time to time on Macs and I do envy how much less RAM they require, BUT everything else is rather clunky on them compared to macOS, IF they even boot.

• TouchPad dynamics are terrible.

• Gestures; forget it.

• WiFi connects a lot slower.

• Skype?... no comment.

• Multiple thunderbolt or HDMI displays with mirroring.

• HiDPI support with lower than physical virtual resolutions.

• Stable Built-in VNC server and client, especially when there are multiple screens?

• Wake up after sleep can still be a problem in 2016 (eg it sets the display brightness to 100%).

and finally why is there no desktop environment which provides macOS' keyboard shortcuts out of the box?

That would really help transitioning from macOS to Linux.

(just to put things into perspective I was an [http://www.6809.org.uk/evilwm/](http://www.6809.org.uk/evilwm/) user for a year back in the day...)

</comment><comment><USER77> I can't even imagine buying an Apple laptop if performance was a critical issue.

</comment><comment><USER78> That FAA thing is bullshit, 160 Wh is allowed in hand luggage just not checked in but who checks a three thousand dollar machine in.</comment>


Emigrant City: NYPL Crowdsources Records of the Emigrant Savings Bank of NYC - <AUTHOR> http://emigrantcity.nypl.org/#/ <comment><USER2> Yet another awesome project created by the NYPL folks. Other public libraries only wish they were that cool.

Personally, I'm partial to their historical menus transcriptions and its API: [http://menus.nypl.org](http://menus.nypl.org)</comment>


EtherPad: Edit Stories Across Computers - <AUTHOR> http://pandoralive.info/?p=2650

<comment><USER2> This is really, really old. Google bought it and incorporated it into Google Docs.

The best fork is Pirate Pad, because it has pirates of course. : )

[http://piratepad.net/front-page/](http://piratepad.net/front-page/)

<comment><USER3> It was an YC company by the way.

EtherPad is among my favourite online collaboration tools. I guess no authentication and plain enough user interface make it a low-threshold choice for all sorts of short term collaboration efforts. I've used it to plan bachelor parties and such.

<comment><USER2> IIRC, AppJet and Meteor folks.

</comment></comment></comment><comment><USER4> Another good alternative is PrimaryPad: [http://www.primarypad.com](http://www.primarypad.com)

<comment><AUTHOR> It seems like the very same thing repackaged to make money off of it with a premium plan, by adding a few features.

<comment><USER4> I am just a customer happy to pay $50 year to have a supported version with a few key features that make it much more useful: private custom domains and private pages to name two.

Their focus is K12 education so I am not sure how much the repackaging was driven by trying to make money but if you are bothered by their motives please don't buy from them.</comment></comment></comment>


Singleton Pattern in Go - <AUTHOR> http://marcio.io/2015/07/singleton-pattern-in-go/ <comment><USER3> It's funny how you can take an obvious antipattern (global variables) and turn it into a pattern by giving it a cool new name like "Singleton". In this spirit, I propose "the ProgramCounterAmbulator" as a cool new name for "goto."

Actually, gotos are usually less harmful than globals. At least they don't interfere with unit testing the way globals tend to.

<comment><USER4> No argument that Singletons make it difficult to unit test things but there are genuine cases where singletons are required: For instance, you don't want to end up creating multiple objects that read the configuration file, when one is enough. Or you certainly don't want to create too many objs that are heavy (like a cache that stores data heavy objects, or services, or god-objects (which are themselves an anti-pattern unavoidable in certain cases)).

At times, there's genuinely only a single entity of "x" that's available for use by the environment, like a security-policy, or access to standard-output, and so on...

Singletons are necessary evil, IMO.

Re: Global state: At some point the abstraction will have to leak. If you squint enough, nothing is truly isolated, and everything's sharing everything else with other binaries on any given system at some abstraction level or the other. This is more often the reason why security-exploits are theoretically possible despite isolation.

<comment><USER5> Depends on what you mean by "singleton". If you define it loosely as "a type of which there is only one instance", fine, no problem -- of course those will exist. But if you define it as "globally-accessible mutable state", then the problems start. Usually, the "singleton pattern" is explicitly a technique for doing the latter.

> For instance, you don't want to end up creating multiple objects that read > the configuration file, when one is enough.

Sure. But that doesn't mean the config file reader has to be globally- accessible. Instead, try allocating it on the stack in your main() function, then passing the object into each component that needs to see it. Better yet, only pass each component a sub-object(s) of the config which applies specifically to that component.

Now you have a bunch of useful benefits:

\- Readability: You can clearly see and follow what components are affected by what parts of the config file.

\- Testability: Unit tests can easily provide a test configuration.

\- Maintainability: If some day you realize that you need to create two instances of some component and configure them differently, it's easy to do that without rewriting tons of code or introducing horrible "namespacing" hacks.

\- Security: If your config file contains anything sensitive (say, database credentials), it's no longer the case that every damned module in the whole system has the ability to read those secrets. In fact, if your language is memory-safe and bans mutable global state, you can trivially sandbox any piece of code by simply not passing it references to anything it shouldn't be able to access. (This is called "capability-based security" or "object capabilities", and it works.)

Extended argument (which I wrote many years ago...):

[http://www.object-oriented-security.org/lets- argue/singleton...](http://www.object-oriented-security.org/lets- argue/singletons)

<comment><USER6> Nailed it. It's fine to use a singleton, but don't call it from within every class you use it in. Just pass a reference to the instance of the singleton. Call it once in the outermost scope.

<comment><USER7> Just wondering what value the singleton provided if you only obtain it once. Isn't the purpose so you can obtain it whenever you want? If you just use a regular object, you run the risk of accidentally making another instance somewhere else, but you always have that risk with any regular object anyway.

<comment><USER6> It's kind of OK to use, as long as you don't call it all over the place and render your code untestable such that it can't be mocked out, but I'm not a huge fan of it. It's really a matter of opinion at that point.

</comment></comment></comment></comment></comment></comment><comment><USER8> It's worth noting that not only do you need to synchronize access to the singleton, you need to synchronize access to the singleton's state as well. And even if you manage that at a fine-grained layer, you're still setting yourself up for all the problems associated with singletons: [http://c2.com/cgi/wiki?SingletonsAreEvil](http://c2.com/cgi/wiki?SingletonsAreEvil).

If you have a bunch of immutable state, then build unexported package variables in the package's `init` func and export funcs which use those variables.

If you have a bunch of mutable state, then don't use a singleton.

<comment><USER9> Do you think it would be fine to use a singleton if the writes are all happening in a single thread and it's not critical that the reads be synchronized? Sharing state across go routines seems like something to be avoided. In vanilla Java it's always not easy to avoid sharing state.

<comment><USER8> If you want your reads to ever work, then they need to be synchronized. Reading from an unfenced address during concurrent writes is undefined behavior for any CPU architecture you can think of, which means you'll get stale reads _in a best-case scenario_. You can also get garbage reads (e.g. as your CPU interprets your read of a 64-bit pointer as two 32-bit reads), crashes, bees, etc.

The code you write is either thread-safe, used in a single-threaded context, or a pinless grenade.

<comment><USER10> There are exceptions to this rule--i.e. there are ways to not really be thread-safe but to have things work anyway--but they fall in the category of "you have to really, really know your CPU and be willing to write processor- specific code that just happens to work", so you can basically ignore them.

My favorite is the libdispatch abuse of cpuid to flood the pipeline on Intel CPUs for this problem: [https://www.mikeash.com/pyblog/friday- qa-2014-06-06-secrets-...](https://www.mikeash.com/pyblog/friday- qa-2014-06-06-secrets-of-dispatch_once.html)

But really, take Coda's advice. If you aren't synchronizing your reads, you can basically just assume your code is broken.

<comment><USER11> An interesting exception is Lamport's Bakery:

[https://en.m.wikipedia.org/wiki/Lamport%27s_bakery_algorithm](https://en.m.wikipedia.org/wiki/Lamport%27s_bakery_algorithm)

Thread safety without synchronisation primitives. I'm not sure it's ever actually a good idea to use it, though.

EDIT: unless you count a fence as a synchronisation primitive.

</comment></comment></comment></comment></comment><comment><USER10> Your "check-lock-check" code is probably broken (depending on the intricacies of Golang's memory model). If the compiler or CPU reorders any stores to the fields of "instance" after the assignment to "instance" itself, other threads could start working with a partially uninitialized object. Once() uses atomics on the fast path for a reason.

<comment><USER12> Totally! I was going to post the same thing. Double-checked locking is either impossible or really hard to get right, depending on the language and architecture's guarantees!

If you must use a singleton, I'd really recommend doing the so-called "aggressive" approach, which should have really been named the "actually won't crash sometimes" approach.

<comment><USER13> +1 for the aggressive approach, mutexes are very fast in go.

I got curious and wrote a quick little benchmark test:

        $ cat bench_test.go
        package main

        import (
        	"sync"
        	"testing"
        )

        func BenchmarkMutex(b *testing.B) {
        	var m sync.Mutex
        	for n := 0; n < b.N; n++ {
        		m.Lock()
        		m.Unlock()
        	}
        }

        $ go test -v -bench=. bench_test.go
        BenchmarkMutex	50000000	        24.0 ns/op
        ok  	command-line-arguments	1.235s

A set of mutex.Lock() & .Unlock() calls takes only 24.0ns on average to complete.

Thus it's possible to lock/unlock more than 41 million times per second on the puny 2011 MacBook Air I used for this.

My .02c:

The post seems like a case of premature optimization.

Resource bottlenecks due to too much mutex locking in go does not seem like a case that will be commonly hit.

With infinite potential bottlenecks, I don't like to spend my time worrying and fussing over things that are:

A) Not yet a problem.

B) Unlikely to ever be a problem or give me grief.

Worrying about the overhead cost of locking falls squarely into just such a category.

<comment><USER14> This has no contention and is essentially a no-op? Or do I not understand go?

<comment><USER10> It is a no-op, but Golang's Plan 9-based compilers don't do much optimization, so they aren't able to eliminate it.

</comment></comment></comment></comment></comment><comment><USER15> This is cute, but I think (someone will correct me if I'm wrong) that the real idiom is: things that would be singletons in Java are instead servers managing a channel in Golang.

<comment><USER16> Why incur the cost and complexity of a channel if what you are doing doesn't require it? Go's sync.Once just implements the check-lock-check pattern. It doesn't use a channel in the background.

In fact, it is better to use sync.Once to reduce the risk getting the semantics of check-lock-check incorrect. :)

[edit: It occurred to me that the parent may be speaking about architecture and not about the singleton's design. From an architectural perspective, there are much better patterns in golang than a singleton.]

<comment><USER15> The architecture! Not the design of this singleton.

</comment></comment></comment><comment><USER17> I thought there was a lot of literature pretty convincingly arguing that singleton is in fact an anti-pattern.

<comment><USER18> There is, singletons are an anti-pattern, they're still interesting to discuss like this in terms of making them safe. In a language with both concurrency primitives and globals singletons have little (no) place anyway. I still learned from the post.

<comment><USER14> Shouldn't there be a disclaimer though?

Or, at least an example of when it would be a good idea to use a singleton over some other pattern?

</comment></comment></comment><comment><USER19> What's the point of a singleton when you can just have variables in an anonymous struct at root level, and functions defined at root as well?

      var server struct {
      	host string
      	port string
      }

      func serverStart() {
      	server.host = "..."
      	server.port = "..."
      }

<comment><USER10> When do you call "serverStart()"? If the answer is "eagerly during startup", there's no problem (other than startup time, of course). If the answer is "on demand", now you have a synchronization problem.

</comment></comment><comment><USER20> This post is chock-full of antipatterns. Both the singleton pattern and double checked locking should be avoided.

<comment><USER21> Yea it's easy enough to use dependency injection to satisfy these supposedly "global" requirements. About the only global state I can tolerate is read-only constants, but even then you are much better off with DI just because of testing.

<comment><USER22> DI is an antipattern.

<comment><USER23> who told you that? you'd better not listen to that guy anymore.

</comment></comment></comment></comment><comment><USER24> Coding Pro Tip: Instead of using the Singleton pattern, make one instance of your class at the start of your program and pass it around to its users.

Singletons are really just as bad as global variables. Why? Because they are global variables.

<comment><USER25> Depending on what you are trying to implement - passing an extra variable everywhere is just creating noise (because potentially you have to have an extra parameter to EVERY function or method). I believe in KISS - <USER2> should be as simple as possible but not simpler. Believe it or not there are valid uses for a Singleton which, many would agree, include a simple logging class [1].

One could argue that you could just create it in the section of code you want to log - but that just creates noise and you end up repeating code.

logger = Log() # run code to open the file to the last position logger.log("test")

vs

Log.instance().log("test")

Now imagine this was a multi-threaded application - singleton arguments are much different.

> Singletons are really just as bad as global variables. Why? Because they are > global variables.

Everyone has their own opinions - but you can't make sweeping generalizations. I'm not saying a global variable is appropriate in every situation - but every language, and project, is different. There are even different dialects of C++ [2].

[1] - [http://stackoverflow.com/questions/228164/on-design- patterns...](http://stackoverflow.com/questions/228164/on-design-patterns- when-to-use-the-singleton)

[2] - [http://www.reddit.com/r/programming/comments/197dn1/introduc...](http://www.reddit.com/r/programming/comments/197dn1/introduction_to_c_a_series_of_46_videos_created/c8lks22)

<comment><USER26> > you have to have an extra parameter to EVERY function or method

Dependency injection provides a pretty good solution to this, potentially even for the logging use case. Classes (or code modules or whatever) only need to think about their _direct_ dependencies, and indirect dependencies are handled naturally by the wiring code. In a well-written codebase using DI, you basically never need to write code that accepts an argument just so that it can pass that argument down to other code.

For example, if a class Foo deep in your program wants to use an interface called Logger for the first time, you just add a Logger as a field and pass the Logger into the Foo constructor in your wiring code. It's a little more ceremony than an import statement, but not by much, especially if you use a DI framework to do the wiring for you. Importantly, you don't need to make any changes to code that uses Foo.

An advantage to this approach is that it makes it easier to test usage of Logger (e.g. asserting that Foo logs an error in a particular situation). It also makes it easier to extend the Logger, like using a Logger wrapper that collects statistics on what was logged, without needing a special extensibility point in the Logger implementation.

That's not to say globals/singletons are always a bad idea. They tend to result in shorter code and they're easier to understand, and you can still test against them if you're willing to use mutable singletons (e.g. monkey patching in Python) or custom extensibility points. My main point is that, if you have a class that's useful in a wide variety of situations, there are other solutions than just "use a global" and "explicitly pass it around everywhere", and IMO dependency injection is one of the best options if you're writing serious code.

</comment></comment></comment><comment><USER27> Wouldn't it make more sense to have some sort of manager that receives information on an incoming channel, manages the state internally, and reports out on an outgoing channel?

<comment><USER28> Abstractly, if you somehow need a singleton object, this will be substantially faster if you need it frequently. And if you're careful to do all the other things you need to do in order to make this work and safe, as seen in the other messages in this post.

Practically, all the examples I've ever of why you'd ever want a singleton are indeed better done as a goroutine server over channels. Within the object you get an implicit lock by virtue of being the only goroutine ever to touch that stuff, and as long as you don't need this object to use more than one CPU total and the overhead of channels isn't a big deal, which again, describes the vast bulk of cases I've ever heard of that call for singletons, it's a better way to go.

And I'd note I've written a couple dozen different goroutine server things and a grand total of 0 'singletons', so... yeah.

If I had an immutable singleton object that was somehow very expensive to initialize, I might consider this approach. Not sure when that would come up but I'm sure it describes something.

<comment><USER18> A singleton is basically a global variable and those aren't really important to "shim" in Go. Object method calls are pretty much the same conceptually as message passing but when you actually need to synchronize as you point out goroutines and channels make things much simpler. I think what this post was going for wasn't "use singletons", it was "look at these interesting threading issues that arise and how we address them in (non idiomatic) Go"

<comment><USER10> There's more that needs to be done if the goal is "look at these interesting threading issues that arise and how we address them in (non idiomatic) Go", because the initialization described in the post is broken.

Shared-memory multithreading is hard. Golang does not do much to prevent you from shooting yourself in the foot here, as this post proves. So use the abstractions wherever possible. In this case, Once correctly performs the atomics, and naive double-checked locking doesn't.

</comment></comment></comment></comment><comment><USER29> This seems more idiomatic:

      func init() {
          instance = &singleton{}
      }

<comment><USER30> If instance can truly be initialized like that, then there's no need for the init() function, just do it at the top level:

var instance = &singleton{}

In fact, a lot of idiomatic Go will ignore the Get() method, exporting the instance itself:

var Instance = &singleton{}

Clearly if you overwrite it, bad things will happen. Don't do that.

There may possibly be a problem with unnecessarily slowing startup times in the case you don't need the singleton and initialization is more complicated than a malloc - in which case, profiling will tell you and you can revert to the method in the blog post.

Remember that Go's strict import/dependency requirements mean you're unlikely to import the package (and trigger the initialization) unless you actually use the singleton.

It is non-idiomatic to use the sync.atomic package.

<comment><USER10> > There may possibly be a problem with unnecessarily slowing startup times in > the case you don't need the singleton - in which case, profiling will tell > you and you can revert to the method in the blog post.

Not just in that case. If you lazily initialize then you can get other things done before—or while—you're waiting for the singleton constructor to run. Global constructors are suboptimal for performance almost as a rule.

</comment></comment></comment><comment><USER31> There's a package for this, if anyone needs this pattern off the shelf: [https://github.com/dropbox/godropbox/tree/master/singleton](https://github.com/dropbox/godropbox/tree/master/singleton)

</comment><comment><USER32> Isn't Singleton's really an anti-pattern? SO discussions here: [http://stackoverflow.com/questions/137975/what-is-so-bad- abo...](http://stackoverflow.com/questions/137975/what-is-so-bad-about- singletons)

</comment><comment><USER33> Two things:

1) Unless you've explicitly checked that Go's memory model prevents read/write moves to allow double-checked locking, don't do it.

2) The pattern is usually a CAS after the check.

</comment><comment><USER34> Why not use an atomic compare-and-swap instruction as offered by all of the major underlying hardware architectures?

</comment><comment><USER35> Oh no.</comment>


A Comparison of 5 Uniprocessor OS Scheduling Policies - <AUTHOR> https://spin.atomicobject.com/2015/04/27/uniprocessor-scheduling-policy-comparison/

<comment><AUTHOR> The previous post: [https://spin.atomicobject.com/2015/02/26/uniprocessor- schedu...](https://spin.atomicobject.com/2015/02/26/uniprocessor-scheduling- policies/)

and discussion: [https://news.ycombinator.com/item?id=9112930](https://news.ycombinator.com/item?id=9112930)

</comment><comment><USER2> At the end of my day and tired, but why is this interesting? I can understand MP schedulers, I was super unhappy with the SGI scheduler back in the day, but MP schedulers are hard, you really don't want to move processes away from their cache if you can avoid it.

Uniprocessor schedulers seem trivial by comparison.

<comment><USER3> I agree uniprocessor schedulers are trivial by comparison to multiprocessor schedulers. However, it's also helpful to learn how to crawl before you try walking.</comment></comment>


Quality Follows Popularity - <AUTHOR> http://dilbert.com/blog/entry/quality_follows_popularity/

<comment><USER2> There are no overnight successes; they are preceded by innumerable days and nights of mediocre progress and failures. These videos on Storytelling have (of course) been posted here before but I love Ira Glass talking about failing on the way to success:

"For the first couple years that you are making stuff. It's trying to be good, it has a mission to be good. But your taste, the thing that got you into that game is still killer, and your taste is good enough that you can tell that what you are making is still sort of a disappointment to you, that it's crappy. A lot of people never get past that phase, a lot of people at that point _they_ _quit_. The thing I would just like to say with you with all my heart is that most everyone I know who does interesting creative work went through a phase of _years_ "

<http://www.youtube.com/watch?v=-hidvElQ0xE> <http://www.youtube.com/watch?v=3qmtwa1yZRM>

> The TV show Friends had a similar path. The first few episodes were awful in > terms of writing and acting.

I remember watching the first episode (pilot) of Friends alone in my dorm room on a Friday, and it was basically a bunch of twenty-somethings loitering in a coffee shop called Central Perk. They never left the coffee shop. No plot, pretty bad, what do these people do for a living? you would never have guessed that they'd become one of the all-time most popular shows and exert a cultural impact.

<comment><USER3> Thank you for posting these videos of Ira Glass. They are very inspirational.

I don't consider myself a creative person, and didn't immediately see how it applied to me. I think the underlying principle is that doing good work is hard, and that you only get better at it by doing it.

</comment></comment><comment><USER4> This is a fine essay on the importance of having a marketable concept.

That said, I'm a bit concerned that he's overgeneralizing from a biased sample set: His major examples (besides his own comic) are TV series. TV series _often_ take time to get started; they always have. To pick some examples close to the geek heart: _Star Trek:TNG_ had a crappy first season. _Babylon Five_ had a very spotty first season.

There's a reason for this: traditionally, the first half-season of the typical TV show was written by a team of more-or-less freelance writers who worked from a "series bible": A big book written by the series creator that describes the characters and the setting and some of the possible plot directions. [1] They might also have had a pilot script, or even an actual pilot, to work from. But these writers would not necessarily have seen the actors performing in their roles. They might not even have known who the actors were. So their scripts would form an odd patchwork that would be stitched together by the producer, the director, and the actors on the fly. By the third season, however, things would have sorted themselves out: The producers would have found a stable of writers they like, the writers would have seen the older episodes and have some idea of how the actors inhabited the characters, there would be a canon to draw upon, and so on.

\---

[1] This has changed, of course, particularly for drama series. _Heroes_ was awesome from the first moment; most people agree that it was all downhill from season one. Other shows -- _Firefly_ , the new _Doctor Who_ \-- also exhibit the pattern of initial awesomeness. This is arguably because the economics of TV series production has changed a lot: The rise of DVD box sets has changed the target audience and the product life cycle for TV series, and the way shows are pitched, produced, and financed has changed. And it's probably also because writers and producers have learned from the experience of shows like _Babylon Five_ and _X-Files_ and, later, _Buffy_ : Show runners seem to have a greater tendency to be highly capable writers who are given much more control over the early episodes, often to the point where they will write most of those episodes personally.

</comment><comment><USER5> "The common notion about entertainment is that the better the quality, the bigger the audience. There's some truth to that."

I think we have drastically different definitions of quality.

<comment><USER6> To be fair, this is Scott Adams. He draws a mildly funny, fairly accurate depiction of life in a workplace. That's about it.

When Bill Watterson writes about quality and popularity, for instance, he's got a much different attitude, something more like "Popularity be damned: this is my art and I refuse to compromise it." I've seen it in every book of his I've read when he talks about work. He made comics primarily for himself, it seemed: it's why people got so much out of them. Scott Adams isn't nearly in the same league. He's smart, but he doesn't have one of the Great Comics.

Sometimes people like that get popular, sometimes not. (To be fair to Firefly: I think Joss Whedon has had more than a fair share of success, and he has more rabid intelligent fangirls than any other person I can imagine.)

</comment></comment><comment><USER7> He's describing High Concept.

<http://www.writersstore.com/article.php?articles_id=609>

</comment><comment><USER8> While I've not had significant successes in a large-scale public sense, on a smaller stage I've noticed that people will respond to a good idea that's been at least partially executed or proven. (Ideas alone aren't worth anything.) That seems to be what he's saying.

</comment><comment><USER9> I appreciate it when general claims are supported with specific evidence, because it gives me a handle to assess the claim, and perhaps disagree.

Here, I disagree with the Friends example: I recently happened to see the pilot (on youtube), and I was impressed with how funny the writing and delivery were, right from the beginning. The production values improved later on (and Joey's clothes changed a lot), but it really seemed the same to me. Note that I'm evaluating it as a series of jokes, which is the primary characteristic of a sit-com (though not the only one).

</comment><comment><USER10> Worse is better?</comment>


Reddit and Facebook Veteran on How to Troubleshoot Troublemakers - <AUTHOR> http://firstround.com/review/reddit-and-facebook-veteran-on-how-to-troubleshoot-troublemakers/ <comment><USER3> >That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else?

I have worked with this person on more than one occasion and I would love to work with them again. Entire new products and verticals are often the result of such projects.

Companies have such a hard time dealing with risk. They think that the only appropriate thing is to always minimize risk. "Look, I have minimized risk at every opportunity. I am doing a great job!" That's not true all the time though. When exploring new business models or in some other situations high risk activity should be preferred.

<comment><USER4> As one of these problem people myself, it's helpful to know that this is considered bad behavior. I'm not sure it should be though...

The thought process is that many times the barrier to adopting a better technology is just the time investment. So if you're sick of working with a problematic system, but the team doesn't have the time to fix it, fixing it away from work might remove that pain point from your life. And since often these projects begin and even end as just an experiment, there's not much reason to tell the team until you have something.

It doesn't really seem to have much of a downside - assuming you're just presenting whatever you come up with to the team later as an option, and not going crazy and replacing production systems without asking.

<comment><USER5> The "without telling anyone else" part is potentially the problem.

Imagine you committed time and energy to build a decent system - not perfect, but most people are ok with. You feel a sense of ownership on this system. Then one day, a coworker of your tells your manager that he has built a new system in his off time. He also made a conscious decision not to discuss the effort with you. How would that make you feel?

<comment><USER6> Yeah. As I've gotten older I've cared less and less for "my code." If the new effort is demonstrably better than the existing system, then I'm happy. Who cares who wrote the old stuff, this is better.

The problem, of course, is that often the new system is not better, it's just newer. Sure, it may be simpler and easier to understand, but is that because it is an inherently better solution, or is that because it doesn't deal with all of the the real-world conditions that the productions system has grown to support over time?

Even then re-writing is often a good thing. You can re-approach the problem domain with all the insight you've gained building the old system.

<comment><USER7> Ideally there would be good enough tests of the old system that if the new system passes the same tests, then there's high confidence that it will perform correctly in production too. That way we get the benefit of being able to refactor or reimplement entire subsystems while still having almost the same assurance as the old system.

</comment></comment></comment></comment></comment><comment><USER8> She notes that she has a tendency to require that the solution work her way when coding.

I wonder if she realizes she's doing the same when working with people's problems? Almost all of those solutions end with, "do it my way or get out."

Not a collaborative coder? No room for you here. Not a people person? No room for you here. Want to use the latest technologies? No room for you here.

For someone who wrote an entire blogpost about the benefits of troublemakers and how to integrate them, she doesn't seem very willing to actually work _with_ them, just to make them work for her.

<comment><USER9> >For someone who wrote an entire blogpost about the benefits of troublemakers and how to integrate them, she doesn't seem very willing to actually work with them, just to make them work for her.

That's kind of the point. You don't want to be working with someone who can't work with other people. If you're a "troublemaker" and refuse to change and adapt to the way the company you work for does things, go ahead and found your own and do it your way, and see if others are willing to work for you in the long term, or find another company with the culture you're after. When it comes to tech there's plenty of companies out there who hire for different personalities and abilities.

<comment><USER10> Yeah, because nobody would want someone like Alan Turing at their company.

The whole "everyone must be a team player" thing is such crap. I will gladly take a one man army with the resolve to deliver above all else over a team of mediocre players who take 4 times as long and waste more time arguing in meetings than it would take to just bust the thing out twice.

Effective teams are great too, but if you can't figure out how to use the other type, it really is your loss.

<comment><USER11> No. Most people _think_ that they are Alan Turing, Linus Torvald, Steve Jobs; are not.

</comment></comment></comment></comment><comment><USER12> Wow fuck everything about this, it sounds like extreme micro management.

The premise here is a) do exactly what you're told and b) in exactly the way we tell you or c) you are mentally ill.

Now I'll agree that some of it is plain toxic. You can't deploy whatever you want to production. But that's one line from an entire article of benign behaviour.

You're REALLY going to crush Mr/Mrs Nostalgia? WHY WOULD YOU BOTHER. If someone saying things were better two years ago is going to crush your organisation then FFS you have bigger problems on your hands.

I'd also like to put forward that if you're a hermit you either may just take pride in your work (a carpenter doesn't go parading around a half built table) or are STILL working in a toxic company (not just came from one so its your fault).

If they're doing the job then for fucks sake let people be rather than trying to invent a job description for yourself which involves "fixing" normal people.

There's a reason people are quitting when faced with this "mentoring" and it's not because they're burnt out.

</comment><comment><USER13> Pretty strange to describe Bethanye as a "Reddit veteran", especially leading the title with that. She worked at Reddit for less than a month.

<comment><USER14> I wonder what happened there?

<comment><USER15> From some minor googling it seems she didn't want to mixed up in Reddit's community problems at the time. [http://thenextweb.com/insider/2015/07/14/reddits-troubles- mo...](http://thenextweb.com/insider/2015/07/14/reddits-troubles-mount-as- chief-engineer-bethanye-blount-quits/)

</comment></comment></comment><comment><USER16> Sigh. Yet more unsubstantiated psychobabble pablum.

Managing people is hard. Mmmmmkay?

My ability to manage is a function of how creatively and effectively I can be in aligning the company's goals with the worker's goals. It won't be 100% (that's why it's called a "job" and we pay people), but most managers barely even try. Funny how "troublemakers" seem to get in line when you actually manage to understand what motivates them.

If a manager can't do that, either A) the manager needs to be replaced or B) the employee needs to be replaced.

The problem is that we don't fire/demote managers nearly often enough, and we fire employees far too often.

<comment><USER17> Did you read the article? A good chunk of it was about understanding the trouble makers to see what motivates them and aligning both the goals of the employee and the company.

</comment></comment><comment><USER18> Nice article. From my experience the biggest troublemakers are often in management two layers or more above and have no discipline in making changes or throwing new ideas into the pipeline.

<comment><USER19> ha! Very same experience here, too. I was just working at a place where one of the designer-founders redesigned a page to look one way. Then three months later, he redesigned it again, to look back the old way. He actually put these into the pipeline, assigned it to different engineers, and there was no reasoning over choosing one way or the other. Both designs had the same functionality and the same glaring flaws. He just kept wavering and wouldn't even consider doing any user testing or A/B testing on it. Glad I don't work there anymore.

<comment><USER20> > He just kept wavering and wouldn't even consider doing any user testing or > A/B testing on it.

That's why it's essential to pre-commit to a culture of testing everything. It's by far the best weapon you have against a founder with a terrible idea that they won't drop.

<comment><USER19> Funny thing was this place did espouse "test everything" except it came in the form of our Product leads "test only the things I don't agree with." Which of course meant we were using all of our _testing budget_ on dumb things.

</comment></comment></comment></comment><comment><USER21> > _THE HERMIT_

> [...]

> _NOSTALGIA JUNKIE_

> [...]

> _TREND CHASER_

> [...]

If you enjoy this sort of "laundry list of named stereotypes" format, you might like "Academic Programmers: A Spotter's Guide":

[http://www.ee.ryerson.ca/~elf/hack/academic.html](http://www.ee.ryerson.ca/~elf/hack/academic.html) [1997]

It's got more of them and they are funnier.

</comment><comment><USER22> I would hate to work for this lady. The fact she labels these archetypes, which are questionable in the first place, as "troublemakers" really makes it clear what she thinks. She's better than her engineers, they're lucky to work for her, and if they're not careful, she'll fire them.

That does not sound like a fun work environment. Not that I'm trying to be a troublemaker... (Please don't put me in timeout!)

<comment><USER23> I didn't get the feeling that she thought she was better than her engineers.

Regardless of that, each of these archetypes presents real difficulties to a team that has to deal with them. A hermit can cause massive troubles for a company if they are doing critical work. In the case that someone is prolematic to the team, it's better to solve the problem than to lose the person, and that's what she tried to do.

<comment><USER24> > I remember several instances when it took a few deep breaths to keep me from > kicking him out. But today he leads a team and triages the troublemakers he > once was. Sometimes when you save a troublemaker, you're saving a team > they're not yet on.

 _She_ saved the troublemaker by taking a few deep breaths, not the team. She blames the troublemaker for his bad behavior, and takes credit for his good behavior.

She does not acknowledge efforts made by other team members, and barely acknowledges the individual himself for the adjustments he made.

She could've written "Sometimes when you _are patient with_ a troublemaker, you're _helping to save_ a team they're not yet on."

We each make our own choices and face the consequences, good or bad. There is room for guides to help people understand consequences. Mentors and managers do not make choices for individuals. Ultimately, each choice is our own.

<comment><USER11> I think she meant it as written. It sounds like she helped refocus the "troublemaker's" energy, language, mannerisms in a way that helped him be a positive contributor rather than someone who was resented by the rest of the team

<comment><USER24> Communication skills and perceptions are everything in the world of interpersonal relations.

You added the word " _helped_ " twice whereas she did not use it in the above quoted comments.

Your perception is different from mine. That's fine. Her phrasing is ambiguous at best, and possibly pretentious.

</comment></comment></comment></comment></comment><comment><USER19> I got to disagree with the whole continuity over ingenuity trope. It's how I can continue to remain modern as an engineer, and if done correctly, leads to vast gains in cognitive complexity by delegating concerns to newfangled tools that handle it better. Sure, it's a bit less stable, but this is how we keep the industry moving quickly, and I hope managers see it more in terms of trading technical debts than a stubborn "oh great, you want to introduce another new tool!?"

<comment><USER25> Right, because your growth as an engineer trumps the company's concerns over having a stable code base.

I can't count the number of times I've had to give some variation on this speech to junior engineers of one stripe or another: The company does not exist to give you cool things to hack on. The company exists to provide a product or service to its customers, from whom it collects revenue, in order to repay its investors, pay its employees and suppliers, and hopefully also make a profit. To the extent playing with cool, new, whiz-bang furthers those goals, it will happen, but whiz-bang is neither necessary nor sufficient for those goals. In fact, whiz-bang for its own sake can often be _inimical_ to those goals.

Also, nice false dichotomy.

<comment><USER26> >Right, because your growth as an engineer trumps the company's concerns over having a stable code base.

When a good engineer can easily move to dozens of other companies, yes, it does. If I felt like my growth had stagnated and my employer wasn't willing to work with me, I'd move on.

<comment><USER25> And I'd submit that a "good" engineer is, by definition, the kind that understands when it's appropriate to use new technologies, and when it's not — and "Look, shiny!" isn't, IMO, a good enough reason.

And pushing — let alone threatening to move on — to use new tools when they aren't appropriate? Please, go be someone else's problem.

<comment><USER27> It looks like you two are in violent agreement.

Here's the problem: _Everything_ , no exceptions, starts out as "Look, shiny!". Usually, you need to play with it to find out if you even have a use case to justify spending the resources to do a formal evaluation. Reading the docs is a poor substitute for deploying it.

Now what the article talks about is "shiny!" being pushed into production. No, no no no _no_. Never do that. There's no excuse for just dropping new untested shit into prod where customers can trip over errors - I think everyone can agree?

But if hypothetical you is preventing your hypothetical engineers from indulging their curiosity and trying out new things to see if there's even a business case to be made for production use ("But there's no time" counts here), you're hamstringing the engineers and hamstringing your business.

<comment><USER28> Yeah, this is a good summary. There should be room for experimentation in isolated, non-production environments if the engineer in question is trusted and can propose a hypothesis better than "I think this will make my resume better". That stuff _shouldn 't_ be rushed out to prod without thorough vetting both internally and externally, which, much to the dismay of junior engineers (and not-so-junior engineers with bad judgment), often means letting a tool age a little bit before you bet the company on its stability. Unless the tool truly revolutionizes your particular line of business, and let me pre-emptively state that there's a 99.99% chance that it doesn't even if you think it does, there is no harm in letting other people be the guinea pigs.

</comment></comment></comment></comment></comment></comment><comment><USER29> TLDR; Oh hello there! I've come up with a faultless way to manage inventive people out of organisations by pitching them as being troublemakers.

<comment><USER12> Write a book, turn it into a TV show, take my money!!!

Wait a minute you didn't make all this up just to make money did you?

</comment></comment><comment><USER30> This is a gold mine, I'm so glad to have found this article, thank you for sharing!

I definitely evolved from "The Hermit" into what I am currently, some form of "Smartest in the Room"(I don't think I'm smarter, I just tend to think the way I came up with is best).

Being a developer is a process! I'm incredibly interested when we stop pretending that everyone's a "rockstar" or whatever, and start talking about the problems that come up, and how to work through them. I'm only just now coming to the realization within the last few weeks that I need to be more open to alternative and intermediate solutions that aren't perfect, but solve the problem for the time being.

Again, thanks for sharing!

</comment><comment><USER24> > I remember several instances when it took a few deep breaths to keep me from > kicking him out. But today he leads a team and triages the troublemakers he > once was. Sometimes when you save a troublemaker, you're saving a team > they're not yet on.

What a saint. Seriously, it always felt funny to me when a team member was let go at the behest of one or a few individuals.

Anyway, the way she says this leads me to believe she thinks she is more important than other people.

<comment><USER31> > Anyway, the way she says this leads me to believe she thinks she is more > important than other people.

She's a manager of course she thinks that.

<comment><USER24> Well that's silly. All managers do not feel that way, and the salary sure isn't higher in many cases unless you're nearing the top of the organization.

Being a manager is simply a different job function.

<comment><USER19> This is where I feel like the title "project manager" ought to be reconsidered, perhaps to "project secretary." That way, it's a bit more clear there's less of a hierarchy and more of a duty.

<comment><USER24> People go on power trips regardless of title.

It's a mentality. You just need to hire people who are both smart and able to do the job, and can also see that all people are equals.

</comment></comment></comment></comment></comment><comment><USER32> Having worked in several divergent fields as a Proposal Writer (aka Team Leader with Zero Authority) - health care, finance, and insurance - <USER2> none of these archetypes are exclusive to engineering or the tech sector. I think they are reasonable break-downs of classification as presented (Hermit, Nostalgia, Trend Chaser, and Smarty) which can be useful to consider in pretty much any professional, team environment. This article could be helpful to get a more relaxed, casual perspective of employees that can be frustrating.

I've often joked that working in a fast paced, multi-deadline Proposal gig, it's like herding cats. Each team might have one or more of these troublemakers - or, worse yet, be the 'name / lead person' running the opportunity - and so learning techniques to work through the challenges became second nature. Always was a fan of Kevin Mitnick, and his guides on social engineering security can be resonably applied in manipulating team members for great good. YMMV.

</comment><comment><USER33> About the hermit: Why isn't the first assumption to look into the company's own culture? I mean you can work on trust as much as you want. If there is no reason to have trust in the team the tactic will fail.

</comment><comment><USER34> This is a good article and reminds me of myself as a young trouble maker in my first major job after graduating. I think I was really pretty hard to work with. Now, not so much. My personal arc reminds me of growing up where my parents, particularly my father, was quite strict. Once I had children of my own, I often heard myself using my father's strict voice quite often.

Her career also reminds me of Gerald M. Weinberg who started out as a computer programmer turned consultant. He eventually realized that many of the problems he was brought in to solve weren't strictly technological, and ended up debugging teams, using her terminology, and that became his career.

</comment><comment><USER35> "For the last 20 years, Blount has led technical teams at a range of companies."

LinkedIn says she was an IC until 2002, and then from 2002 through 2006 she was a "software design/project management" which is also an IC role. So really she's been leading technical teams for at most 10 years, which is not someone I would suggest anyone turn to for sage and experienced advice.

<comment><USER12> Sorry what's the IC acronym?

</comment></comment><comment><USER36> None of the examples of troublemakers are management or HR.

it's not that those people never cause trouble. It's that the trouble they cause is something we are forced to accept.

</comment><comment><USER37> The way in which this site keeps bringing up a layer to get me to sign up for something everytime I go away from reading what is an interesting article is infuriating.

</comment><comment><USER38> I'm glad that humans fall so neatly into a few distinct categories.

</comment><comment><USER39> Great PR.</comment>