Why I often implement things from scratch (2006) - <AUTHOR> http://armstrongonsoftware.blogspot.com/2006/09/why-i-often-implement-things-from.html <comment><USER2> There's a clear-cut "scissor statement" that you can use to divide programmers into two opposite sides. You ask the following question:

"\--If you need to invert a 2x2 matrix in your program, do you write down the algebraic formula for the solution by hand or do you call a linear algebra library? (that you would not need otherwise)"

The answer to this question is _obvious_ to most programmers. Also, it is obvious to them that the opposite answer is clearly wrong and absurd. Unfortunately, not everybody gives the same answer!

<comment><USER3> Okay, you got me. I am in the camp that says calling the library is (in the general case) obviously the better choice.

My (camp's) reasoning:

1\. Your handrolled solution is likely worse than the library anyway

2\. You're wasting effort reinventing the wheel

3\. You risk adding unnecessary opacity by littering the program with dense math

4\. Other programmers will assume there is a pertinent reason you handrolled the algorithm instead of using the library. Now everytime someone touches that code they have to reverse engineer your approach to see what it does different from the library such that you had to roll it yourself (surprise: nothing!).

The two exceptions I imagine are 1) if you really do absolutely need some slightly modified microoptimization of what the library does or 2) if you are working for a platform where there is good reason to avoid even slight bloat (embedded).

For the people who read OP's comment and believe I am (obviously) wrong, what is your camp's way of looking at this?

<comment><USER4> > Your handrolled solution is likely worse than the library anyway

This assumption led to a lot of O(n^2) left-padding happening over the years, via _left-pad_ from node.js.

Ideally libraries would be well-tested and of high quality, but at this point there may be too many of them to vet.

My own 2 cents is that if it's easier to implement the code from scratch than to evaluate and choose a library, perhaps the invent-it-here choice works best.

<comment><USER5> Parent's comment is getting downvoted to all heck, but it is _completely, obviously_ true in the Javascript ecosystem. If you're a competent-to-expert Javascript programmer, you will regularly run into libraries that are not coded to your standards.

And honestly, even throwing those libraries out, it's sometimes not even a question of doing a "better" job than the library. The library is designed for general-use, but my needs aren't always general-use. Sometimes libraries are _good_ , but they're wasting time on stuff that I don't need.

This is the reason why every Unity game on the web takes 4-5 seconds to load, and my custom engine takes on the order of milliseconds to load. It's not because I'm a better programmer, it's not because Unity devs are crap, it's purely because I know exactly what my engine needs to do, and I don't waste time on anything that it doesn't need to do.

I can think of tons of examples where I've started out using an existing library and then realized that getting rid of abstraction made my code faster and easier to debug. Heck, I can think of tons of times where I've privately forked libraries and deleted codepaths or rewritten algorithms to make them more efficient for my use-cases. There are very few JS libraries that I regularly use where I have not at some point needed to care about their internals.

And I am definitely not a crazy, insane, masterful programmer. If I'm occasionally circumventing d3 internals or doing stuff manually, it's not because I'm special. People have this assumption that if something has a bunch of stars on Github, there's no way they could possibly code something more appropriate or efficient, and for a lot of people, that just isn't true.

<comment><USER6> "Surely this core cryptography library with 21 contributors and led by a superstar Node.JS dev with 9+ million weekly downloads and 1000+ dependants will be a great example to read and learn from..."

 _Opens source code._

 _Closes source code._

"Well, looks like I'm going to be a Rust developer from now on."

<comment><USER7> Just don't ever look into the crates, as long as the lid stays on the crates are perfect, no reason to believe otherwise.

</comment></comment></comment></comment></comment></comment><comment><USER8> Too many devs don't understand that dependencies add fragility to a system.

The larger and more complex a system you design, the more likely it is that you end up with something breaking because two dependencies are incompatible or even your code and a dependant break due to updating the dependant.

Further, security is rarely considered. The more code you have, the more likely you are to have a security vulnerability. You have to worry not only about code you maintain, but also the code of your dependencies.

If you can write the functionality you crave rapidly, do it. You'll save yourself (and others) headaches in the future.

<comment><USER9> Or worse, the developer gets bored and stops supporting the project, and it stagnates until it breaks everything else. VisionEgg I'm looking at you.

<comment><USER10> Except that happens far more often when you roll your own code internally. For anything of even moderate complexity, only the author will know how it works.

<comment><USER11> If this person is bad at knowledge transfer, they end up being the only expert and thereby gaining status for having done so, when objectively this should cost them status instead.

</comment></comment></comment></comment><comment><USER12> Once upon a time there was a systems programmer who wanted to use a readymade 3rd party solution to an specific problem.

He evaluated 3 options, then downloaded, compiled, configured and integrated the best choice into the project over the course of a full day. Its limited database integration configuration necessitated some odd quirks like duplicating a db column, but oh well.

When finally done, integration tests revealed that it didn't actually solve the entire problem. It only solved 90% of the problem. Not only that, it had a significant but elusive bug that only occurred in 5% of situations. He filed a bug report, but the project hadn't received any updates in over a year. Damn.

When it became clear neither of the other two readymade libraries would solve 100% of the problem either, the programmer wrote his own solution. It took 3 days of work but he learned a LOT about exactly how it works, and the result solved 100% of the problem with no major bugs.

All of the quirks disappeared. The solution fit the problem exactly, and remained flexible and maintainable. It eventually served as a solid foundation for future developments which had no readymade solution.

<comment><USER11> There's a questionnaire out there for anyone writing a library and the first couple of questions are what ones did you try, why don't they work, and why can't they be fixed. Sounds like your coworker wrote a library the "right" way.

We had our own snowflake wrapper around the saucelabs client. I eventually figured out how to file a PR to do the same. Now I get to use that solution on every other project I ever work on. I have similarly used my own Stack Overflow answer to solve a problem I also had three years prior. And I recently found my SO answer to another question verbatim in our own codebase. Ironically, from a guy who often ignores my advice.

Get as many things out of your head and into the group memory as you can. Things get forgotten otherwise. Speaking of, did you guys ever consider open sourcing his solution?

</comment></comment><comment><USER10> While the author's main point has some merit and is worth discussing, the example chosen is wrong, and the reason it's wrong is the reason you should take a beat before you consider ever rolling your own solution.

So now we've got some simple code to copy files between machines, because we hired someone who was too academic to figure out how to set up a simple FTP server. Here's what comes next:

1\. We need to open firewall ports so these two machines can communicate. What are they? Who knows. If it were FTP, the sysadmin would know.

2\. We need authentication; we can't just allow any old machines to connect. If we were using FTP, we'd have that built-in. And it would have been audited, so we can have at least baseline confidence in its safety and accuracy.

3\. We can't go having the disk overflow. We need something to manage quotas, because even though we trust our users, sometimes software goes rogue. Maybe the default FTP server can't handle this, but some other product can.

4\. We need logging so there's an audit trail, in case something goes wrong and we need to track it down.

And on and on and hey look you've reinvented FTP and now no one else on your team knows how it works, it's full of bugs, you've hardcoded a bunch of inefficiencies, there's no documentation, we have to explain what it is and how it works to the operations team, and hey here comes the boss asking us to make sure it works over SSL.

If you think you can do it better, make sure you think about what you're doing.

<comment><USER11> Maybe the two most painful experiences in my career are the customer who changes his mind every six hours (and once a week that happens twice in one day) and when the smartest person in the room is also the biggest fool. They can write the most arcane code that nobody else will want or be able to try to untangle, and then act surprised when people are frustrated with them.

</comment></comment><comment><USER13> This is extremely context dependent. For instance, a dev has to consider:

\- guess whether or not this is an isolated case, or whether or not this will become core functionality

\- a self-assessment of the true difficulty of the problem

\- a self-assessment of their own skills and knowledge in the area

\- security reasoning

\- API access/readabilty for other developers to use this code

\- maintainability of new code

I have personally seen personal implementations that lead to bug, after bug, that have already been reasoned about in equivalent libraries.

Often for the simple fact that other devs who have to work on this code, its likely that the abstraction and readability of a third party library is probably greater than the 'quick-and-dirty' implementation.

<comment><USER11> That's a good list. I'd throw "facility at evaluating existing solutions" on there, too.

The person who reaches for the "New File" button is often not used to asking if the thing they need already exists. They can end up duplicating or triplicating business logic which results in other engineers confidently declaring that a problem has been fixed when they only fixed the obvious occurrence.

</comment></comment><comment><USER5> > If you have the right tools it's often quicker to implement something from > scratch than going to all the trouble of downloading compiling and > installing something that somebody else has written.

Heavily agree. Shameless self plug, this is the philosophy behind Distilled[0]: provide a good-enough, low-abstraction tool so you can build on top of it without it getting in your way or forcing you to memorize configuration options.

Adding unnecessary black-boxes to your code can occasionally come back to bite you. I try not to be religious about this, but I am a little biased towards avoiding the abstractions of the 3rd-party libraries unless they come with a lot of benefits. A big "aha" moment for me was trying to teach interns how to use Grunt/Gulp, and eventually realizing that just teaching them Bash was easier. Then I started noticing other stuff -- for example, that the documentation for our inline documentation library was longer than some of the documentation pages we were generating with it.

There's a principle here that's true for abstractions in general[1], but I find it is especially true for some 3rd-party dependencies. I regularly need to read the source code of 3rd-party dependencies that I use, so I no longer treat them as free.

Obviously this stuff isn't a hard rule. I still use 3rd-party dependencies. But there's a balance here. You should be at least a tiny bit cautious about ready-made solutions.

[0]: [https://distilledjs.com](https://distilledjs.com)

[1]: [https://peertube.danshumway.com/videos/watch/2daaee22-4d92-4...](https://peertube.danshumway.com/videos/watch/2daaee22-4d92-47cf-a211-9d44a5e3e50a)

</comment><comment><USER14> if any given task is trivial (eg. can be done within minutes manually) author's method is the way I go too.

Instead of downloading node.js application with numerous dependencies, I also prefer implementing it in few lines of code.

Some can claim running a 'proper' application (like nodejs/express with JWT authentication) is better. But if your business not solely depend on your solution, trivial stuff wins on the long run IMHO.

Of course security/access-control is debatable...

<comment><USER11> I don't think anyone is suggesting downloading a library is better than writing a single short function. It's a false dilemma.

People who are salty about this subject have dealt with NIH situations where people think they can do better, and are either wrong immediately, or become so when their attention shifts to some other problem.

I have written and maintained internal libraries. Many times it's the wrong choice, sometimes it's the only choice. But I'm also more responsive to feedback than the NIH bozos my coworkers typically complain about, which may in part be why I get to hear about their grievances.

There's an old half-joke, half-theory that we should elect a President who doesn't want the job, instead of people who do.

You should have the individual contributor who doesn't want snowflake code write the snowflake code. They'll keep it no-nonsense.

</comment></comment><comment><USER15> Imagine you have a project where you need to draw a fairly complex object. You have found a file in a standard format that you can use.

However, there are 10 dependencies, some of which are non-trivial. You spend 4 hours changing versions of libraries, downloading a newer compiler than the one you are using, and never get the thing running.

You could have slapped some code together to read the file, and then draw it yourself. It would have taken a half hour.

However, later on you are tasked with with representing many more objects, which have corner cases you didn't account for. This eats up hours and hours of development. Also, you're then tasked with drawing those objects in many different ways, more and more development has been added.

The two take aways are choose based on what you have to do, and make that choice based on knowing 100% what you have to do. If a customer can't make up their mind, they're hurting development whether they know it or not.

BTW, the objects were GIS shapefiles.

<comment><USER16> If there is a domain I would not DIY, it is GIS. It is very often much harder than it looks. Was by any chance one of the dependencies GDAL ?

<comment><USER15> basemap, maplotlib, geos...

The easy solution was to just use Conda.

</comment></comment></comment><comment><USER17> Sending data between two machines should not be difficult even in 2006, and this post shows that it isn't. However the author seems to want to imply that this would hold for _any_ task, which is of course totally false.

</comment><comment><USER18> Writing from scratch costs more, but provides full scope for creativity. Reusing increases productivity, at the costs of reduced scope for creativity, along with other hidden costs..

</comment><comment><USER18> I wouldn't call the article biased, but I don't know many people who can write erlang while I do know many who can write Java, c#, c++

The code and steps needed to compile/bundle/start/maintain for many other languages would be far more than in erlang or other beauties.

Where are the tests? Even in erlang, unit tests are useful. Why would I trust my code? What about security? You might not want this server to allow nasty things to happen if unintended use takes place.

So even in this particular case, I think it is worth evaluating opensource solutions, their maintenance, their license, and have a proper server in place that will be far easier to maintain and trust its robustness (security and availability)

<comment><USER19> I think it is fair to assume that Joe, the original author of Erlang, was working on a project that already was using Erlang. Sadly, he is not around anymore so it is not possible to bring clarity into the particulars.

</comment></comment><comment><USER20> An important reason to try it from scratch first is that it helps your understanding of the problem. That way, you can either confirm that it's better not to take on a dependency, or leverage the experience to find, evaluate, and appreciate the right dependency when one turns out to be desirable. Just like people build their own web frameworks before they settle for an established one. That's a good thing, in my opinion.

</comment><comment><USER21> RIP joe We miss you

</comment><comment><USER22> The biggest reason to introduce dependencies, in my mind, isn't immediate productivity boost, but:

> With enough eyes, all bugs become shallow.

</comment><comment><USER23> Everything is easy when you know how to do it.

It's that learning curve. . .

<comment><USER24> right. the other side of that learning curve is that if you implement some X instead of integrating a third party library..even if you didn't before, you now know a lot more about X. enough that you might be able to debug issues with X, or have an informed opinion as to the quality of other implementations of X

</comment></comment><comment><USER25> [https://xkcd.com/1205/](https://xkcd.com/1205/)

<comment><AUTHOR> That's a nice chart to keep in mind, but kinda tangential. Joe's point is that with the right tools, it is sometimes faster to write your own solution than it is to pick one from all the available canned solutions and learn to build & install & configure & use it (and figure out what to do when it doesn't work like it's supposed to).

<comment><USER26> > Joe's point

I think his point is more it's faster to solve the problem you have ("I want to get files from machine X") rather than the problem you imagine you have ("I need an FTP server") - it's just wrapped up in "I solved it myself using Erlang".

<comment><AUTHOR> Well both Joe's program and an FTP server & client are possible solutions to the problem "I want to get files from machine X."

But I very much agree that the speed of the custom solution can in large part be attributed to the fact that you can reject the cost and complexity of existing solutions like FTP (which set out to solve more than just Joe's immediate problem).

Similarly, I often transfer files by piping them to netcat.

EDIT: the point about tools still stands. For example:

        host1$ nc -l 1234 > my.file
        host2$ cat my.file | nc host1 1234

This is very easy to do given that unix is my toolbox. It'd be much more involved to write from scratch in (say) C.

On the other hand, Joe's tool is much more powerful; it doesn't require him to manually interact with the shell on two different hosts, and his program can list files on the remote host and automatically download them under the correct name whereas I'm stuck manually redirecting nc's output to the right file (and cursing myself when I accidentally forget to change the name and overwrite a file I wasn't supposed to fetch). Those features were very easy to add to his program because Erlang is a powerful tool. On unix shell, it's much harder.

<comment><USER27> Consider adding 'tar' on each side to avoid naming errors. If you squint just right, 'tar' is "the pipe fitting that remembers what things used to be called." :)</comment></comment></comment></comment></comment>


Burnout is caused by resentment - <AUTHOR> http://iamnotaprogrammer.com/Burnout-is-caused-by-resentment.html <comment><USER2> I'd agree.

Every time I've quit, it's because I felt I was repeatedly getting the short end of the stick, and management was expecting me to roll over every time I brought such things up.

I quit my first job at 15 1/2. I worked at a Wal-Mart during the summer to buy a computer. I covered 200% more departments than I was hired for. I never took a day off, despite coworkers just not showing up so they could go to the beach. My department manager LOVED me. After my 3 months, I got $0.24 of my $0.25/hour potential raise. I asked the store manager responsible as to why I didn't get the other penny. His answer was utterly asinine. He expected me to go back to work, understanding. Instead, I called my mom and went home, never to return.

The next two jobs I was vastly underpaid. I knew this because vendors, contractors, my own boss and even the office manager told me, quite literally, that I was getting screwed. I was told to man up in response to crappy raises. Instead, I found better jobs that were willing to give me 25-30% more just to walk in their door.

At one place I blew the doors off of all expectations. I qualified for well above the normal bonus. 32%. I was denied because in order to get the bonus I had to have been there since July 1st. My start date? July 3rd. It's not like it wasn't going to be pro-rated, or cut in half. I simply wasn't going to get it. 32% of my salary was a chunk of change large enough to buy a family sedan, cash. Obviously, I made an issue of it. I had vacations denied and had already dealt with that. When a partner said that there was nothing he could do I gave him my curt two-word response and walked out the door... to basically get my lost bonus half as a signing bonus, and the rest over the next year.

Employment is a two-way street, and when you also decide to make it known that my contract is "at will", be advised that I'm aware that I can just not show up anymore, just to make the point. And even though I won't do that, I know I could. At the very least I ask that you demonstrate it, and ensure that I feel appreciated. If you don't, don't be all that surprised when I jump ship at a moment's notice. It's not rocket science -- put your best foot forward, and if you can't, explain clear as day why you can't. Show some humility, and don't expect me to simply sit there and take it, especially in this market. I'm pretty good about making my happiness unknown, and giving organizations months and months to respond before I finally depart. However I've worked with folks that their mentality towards burning bridges is more akin to Aliens: they don't burn bridges -- they nuke them from orbit, just to make sure.

People do business with people they like, and your employees are not exceptions.

<comment><USER3> What you describe isn't burnout though.

<http://en.wikipedia.org/wiki/Burnout_(psychology)>

<comment><USER4> There does seem to be some confusion about what is and isn't burnout. This link might help. While it's aimed at doctors rather than tech workers, it does give you some idea of the mindset involved: [http://www.ucl.ac.uk/medical- education/medical-education-stu...](http://www.ucl.ac.uk/medical- education/medical-education- studies/1991cohort/ScoringAbbreviatedBurnoutInventory.pdf)

</comment></comment></comment><comment><USER5> no - resentment leads to "being pissed-off enough to go work somewhere else".

please, lets keep "burnout" for _burning out_. you know: when you're in a foetal ball sobbing, begging for it to stop; when you need years before your work is enjoyable again; when the client liaison goes on leave after an "accident" with a knife.

there is a difference between that and "resentment".

<comment><USER6> Yup. If you're resentful, you are antagonistic towards your boss and your co- workers. You'll be ready to quit.

If you're burned out, you're probably hardest on _yourself_. It's been described as a 'crisis of self-efficacy'. I suspect that burned-out employees often don't have the self-esteem to quit, until it's absolutely necessary for health reasons or they get fired.

That said... going back to resentfulness... if someone believes they're being gypped by their employer, perhaps that punctures some of the illusions we all have about work. A lot of us knowledge workers strive more for praise and recognition than we do for salary, a fact that our bosses exploit. Maybe the kind of 'burnout' that Marissa Mayer describes, I would call 'waking up to reality'.

</comment></comment><comment><USER7> Haha. I am currently going through this phase at my current firm. I can almost track how I have reached this phase:

1\. I find on the first day that in the nine months before I joined the company, three people who were doing the same stuff I do were fired.

2\. I make an expensive move from a different state. Then on the first day get told that the move in contract had changed and was forced to be sign the new one. An interesting contract that tells me even if the company folds for no good reason of mine, that I would have to payback moving expenses.

3\. I get to spend a significant amount of my personal free time outside of company hours on company "bonding activities". I don't mind being told to go on company dinner fests but don't make it a habit and make me miss my own personal life. I like you as people I work under but you are not my friends and you are certainly not my life.

4\. For a company that makes $2000 plus per engineer, its fun to see how cheap they are. A nice ergonomic chair? Nope. Traveling 50% of time across a few time zones? Make sure you book the cheapest possible flight that you get (irrespective of the number of stops that you have).

Tiny small things that added up gradually and have led to this situation.

<comment><USER8> re the bonding activities: i've decided they should a) be fun and b) be instead of work. otherwise it's just forced.

</comment></comment><comment><USER9> This is wrong. It is only one reason for burnout. I have another.

I burned out because I can no longer care enough about what I'm doing at work to motivate my mind to work on the task at hand. It seems fruitless. People can try to convince me there is some good it is doing, but I see only waste and politics. That resentment is not because my workplace doesn't care about my family. They treat me better than any place I could ever hope to work for. The only sacrifice I've had to make for work is my sanity. I cannot stand development anymore, nor technology, nor I.T., but I'm incapable of doing anything else. I've read the books that say I must love what I do, but I don't, and there is no option to love what I do. I have chosen an occupation and career that no longer suits me, and I have no alternative. I am the only one with a job in my family. I cannot fail. I have to trudge on. This is burnout. I have no where to go.

Therefore, I would state instead that burnout is caused by lack of hope.

<comment><USER10> I am sorry but it sounds more like you are suicidal than burned out. You may want to talk to a proffesional.

<comment><USER11> No, I'm not suicidal. Thanks for stating that, as I'm sure some might be in that situation.

I'm just experienced in a different kind of burnout than what the OP was talking about. And it's a kind of burnout that a number of developers experience at some level after some number of years, but frequently not the sort that you find on HN. I've tried to fix via sleep, exercise, losing weight, etc. and that surely helps but it doesn't fix it. In addition, placing power and trust in the employee definitely helps in that case, as a lot of what drives it is a mix of poor health due to lack of sleep which there are fixes for, lack of ability to concentrate, and weight/fitness, but an important component is out of the control of the employee: the developer/IT employee notices that we all seem to fuss about things that in the end don't really matter, because all code is thrown away, all implementations are replaced, and there is nothing left standing of what is created, and in the end we would seem better off and the nation more employed if that technology weren't distracting everyone. However, activism is not the answer. Technology is inevitable. So you want to become a landscaper, a bartender, or anything to get over that feeling, but you know you can't provide for your family if you do that, so you have the privilege of suffering in a job you hate, knowing that you are spoiled for complaining about a job that pays well. You can't even feel good about complaining.

I've also experienced the other kind of burnout which is what developers usually mean, which is burning the candle at both ends to meet demands you didn't set at work and could not influence even though you tried diligently to, so you have a period of lack of motivation or effectiveness. The result of that for me was that I never want to work for a startup again, because you can get sucked into the idea and the promise- the hope- later to realize that they are desperate and do not care about your family. That is what the OP's post is about, and they are framing it like it can be solved by the employer. Perhaps.

<comment><USER12> Actually, I shouldn't have said the latter is what the OP's post is about, because being overworked and mismanaged is only one reason for resentment. Resentment could be caused by a number of other things. However, I stand by my original point that hopelessness is another reason for burnout.

</comment></comment></comment></comment><comment><USER13> I find that wasting my time is a larger annoyance than monetary compensation. As I get older I have less tolerance for meaningless meetings and the requirement to work specific hours or be in a physical office for a client just because it makes a manager feel better.

<comment><USER14> If you call being sick of meetings and having to come in at specific times "burnout", you have a very mild case of it.

Burnout started for me when I noticed that my interests weren't aligned with my company's interests.. or with _any_ company's interests.. or even with my profession's interests.

Coding became boring. So I switched to doing sysadmin. Then sysadmin stuff became boring. Then technology in general became boring. I just didn't care to learn another stupid language or configuration syntax for products I didn't care about and companies whose success or failure I couldn't give two shits about. I didn't care about the clients. Or the users. Or my coworkers.

Not caring. That's a big part of it. So's lacking interest. At times I'd stop caring about anything. Other times I'd care about things, but they weren't things having anything to do with work.

Everything to do with work became a severe chore at best, and a complete nightmare at worst. It all seemed so fake and full of bullshit -- from the company's stupid pep talks or fake parties and dinners where everyone pretended to like each other and kissed up to their bosses.

When I finally quit it felt like such a relief. Quitting days were some of the happiest days of my life. I did that a lot.

That's burnout.

<comment><USER13> I'm not saying that being annoyed at meeting == burnout. I'm saying that it is a contributing factor just like resentment over unequal compensation, etc.

<comment><USER14> Sure. It all comes down to having a job you don't want to do, for one reason or another, but are nevertheless doing.

The more you don't want to do that job, the less you want to be there, and the longer you stay anyway, the more burnt out you'll be.

Many factors can contribute to this, including relationships you have with the people at the company, your feelings towards them, your job, and the company, and how you feel you and others at the company are treated.

</comment></comment></comment></comment><comment><USER15> Perhaps one of the causes, but in times past I've definitely started to get burned out on projects I did not resent- that were simply truckloads of work, with limited time for sleep/food/unwinding.

On the bright side, that was much easier to recover from than the soul- crushing burnout I associate with resentment.

<comment><USER16> ...so it sounds like you resented that job due to giving you limited time for sleep/food/unwinding?

<comment><USER15> You can lose motivation to do something without resenting it.

<comment><USER17> I agree, but I think burnout and low motivation aren't necessarily the same thing.

</comment></comment></comment></comment><comment><USER18> Most here have commented 3-4 hours ago, but 2 hours ago Isaac Yonemoto left an excellent comment on the blog. So if you read this message, because you're checking the thread for new discussion, I encourage you to check out his comment as well. :-)

<comment><USER19> Yes, he says something like you burnout when you effectively condition your brain to associate work with failure.

</comment></comment><comment><USER20> I agree. The biggest reason why employees (or hell, founders too) quit is because they don't feel appreciated.

If I'm working 60-70 hours a week and have a never-ending stream of people inside the company griping at me about why I wasn't able to get non-essential- to-my-role task X,Y, or Z done for them (this is what being in a big company feels like) - that really starts to mount even for employees who know that they're appreciated by their immediate peers and leadership.

Being appreciated by your managing team or your peers isn't enough - YOU need to feel like you're doing a good job. Even someone with a stalwart self- sureness will crumble if they feel like they're constantly failing to deliver what the business needs.

<comment><USER14> It's about more than just feeling appreciated and feeling like you've done a good job.

I had both, and yet I still burnt out.

What was lacking was fulfillment -- the sense that the work you do is meaningful for you.

Ideally, your job should be interesting, fun, stimulating, and you should feel that what you do is important. If it's stressful, it should be at a level of stress you can deal with, and the stress should be of a positive sort, not a negative sort.

At some of my jobs I was greatly appreciated, and I knew I was doing a great job. But the work was boring, I didn't feel it was important, and it was extremely stressful. So I burnt out.

</comment></comment><comment><USER21> Most people on the thread have this correct: there is a difference between resentment and burnout. I understand this innately, as I've been there with both feelings, and they are quite different.

When I felt burned out, it was literally like a flame on a match stick. I was exhausted and didn't see a way out of the situation (amazing what a little perspective will get you.) I didn't want to do my job, because my head was full and it felt heavy to me.

Contrast that with resentment, and I was pissed off (and motivated.) I had energy to change the situation, which was entirely different from feeling burned out.

One situation gave me energy and focus; the other felt like an immovable burden. Big difference to me.

</comment><comment><USER22> What are the average work hours per week and days' holiday a year taken by a (US) Googler?

<comment><USER16> I don't know that there's really that much data on the subject (and if there is, I probably wouldn't be able to disclose it). I will say this though: I've never been asked to work long hours. Nor have I ever been assigned enough work that I've had to work long hours. We tend to not have fixed deadlines, so it's rare that I have to work in crunch mode. Some people _love_ their jobs and work at all hours. Google is more than willing to accommodate those people. Me, I strive to get a lot done in little time so I have more time to unwind and can be more productive the next day.

TL;DR - It depends.

<comment><USER23> The interesting thing about a culture where the long work day is more common than not is that it starts becoming an expectation even though it isn't codified in any rule. So for example you'd be less likely to get a raise or promotion than a person who puts in more hours than the required. So even though you're not abusing the company you get less benefits for doing the amount of work you're getting paid for.

<comment><USER24> _So for example you'd be less likely to get a raise or promotion than a person who puts in more hours than the required._

If person A does more work than person B who should be promoted and paid more? Some people get more work done than other people because they are smarter. Others get more work done because they simply put in more hours. Is there really much difference between the two?

<comment><USER23> In principle, I agree wholly. In practice, I think hours often gets used as a substitute metric for amount of work done or value brought. It's this substitution and the (possibly unconscious) merit given to extra hours over extra efficiency.

</comment></comment></comment></comment></comment><comment><USER25> At the risk of making everything about Google... I'm going to talk about Google (with the disclaimer that I've now worked here for only ~1.5 years so I'm not authority, etc etc).

stcredzero mentions a laundry list of soul-sapping bad behaviour and in previous jobs I've suffered through (or quit over) probably all of them at one time or another.

There are some subtle yet fundamentally important differences in how Google (from my experience) approaches software development that end up addressing a lot of these.

1\. Most (if not all) engineering managers are... engineers. I've seen internal job postings for engineering directors (to put that in perspective, an eng director might have 30-100 engineers under him or her typically with some engineering managers in between although some particularly senior engineers may report directly to their director) that call for "deep knowledge of C++". Some eng directors still submit CLs. This is something Google takes very seriously;

2\. As an engineer, I don't have to work for you (where "you" is any particular manager or director). This is _incredibly_ important because it puts strict limits on how much crap you can be given because (assuming you're in good standing) you can request a transfer to any team that will take you (within limits and your existing manager can delay you but can't block you);

3\. Internally, Google is _extremely_ open with what's going on in the company. There are a handful of things off-limit but in almost all cases you can view the data and code and announcements for almost every project in Google;

4\. The level of meetings and overall bullshit has been, in my experience, incredibly low compared to previous employers;

5\. Performance reviews are peer-driven. This system is not perfect and you'll have critics who point to thinks like you need senior people around you to get promoted. Some of these claims have merit but the system while not perfect is still (IMHO) very good; and

6\. Gratitude. As Steve Yegge [1] puts it:

> You can't help but want to do your absolute best for Google; you feel like > you owe it to them for taking such incredibly good care of you.

I find many of these alleviate burnout by way of mitigating resentment. I'm not sure I fully agree that burnout is solely caused by resentment however. I've known people who have been well-rewarded and respected for what they've done but they just reach a point where they need a break and have to do something else. I'd characterize this as burnout but perhaps definitions vary.

Lastly, I'll touch on a point someone else mentioned: as time goes on my tolerance for bullshit and time-wasting goes down. No I'm not going to your daily standup ("mini performance review") because it's a waste of my time. No I'm not going to work on your shitty project that's made shitty technology choices for political rather than technical reasons. I don't have the time nor inclination to indulge you in this.

[1]: [http://steve-yegge.blogspot.com/2006/09/good-agile-bad- agile...](http://steve-yegge.blogspot.com/2006/09/good-agile-bad- agile_27.html)

<comment><USER26> > you feel like you owe it to them for taking such incredibly good care of > you.

As a recovering academic, I felt a twinge of horror when I read this. When I didn't love the work I pushed on mainly out of guilt, and it was more than I could carry after a while. Maybe I should have tried resentment.

<comment><USER27> As another recovering ex-academic, I would often tell my friends that academic science (biology in my case) keeps 90% of people around because of guilt and a misplaced sense of honor/duty.

<comment><USER28> But my impression is that in the lab sciences (or any crunch mode job) you are made to feel that everyone relies on you so you are stuck taking care of them, whereas the gratitude model is that the company is so nice to you that you want to earn the respect they give you.

<comment><USER29> Actually, it's more subtle and more pernicious in biology. First, you make sure that your wage slaves have no marketable skills (a PhD in molecular biology is comparable to a community college graduate). Then you carefully isolate them from all perspective and knowledge of career tracks other than the academic treadmill. Finally, you dangle the PhD in front of grad students ("You can't quit now, you won't get anything! You have to hold on until you have the degree! It's all or nothing!"), until they've sunk so many years in that they aren't willing to abandon the sunk time. Then you set up a culture where ridiculous hours and inadequate support are considered normal and make the payoff for the bosses be to get as much labor out of someone as they can get before shoving them out the door to the next slave master. The behavior of your average professor towards his lab would have him slapped with lawsuits in normal work environments.

</comment></comment></comment></comment></comment><comment><USER30> You can get burnt out all by your lonesome self just fine without resenting anybody or anything at all.

</comment><comment><USER31> Unplug for merely a week? How very masochistically American. Let me teach you something about burnout, you poor, pathetically narrow-minded little man. I'd like to unplug for six months out of the year, at an absolute minimum. That's burnout, my friend.

<comment><USER32> Is it just me, or is insulting + judging + stereotyping someone the epitome of being narrow-minded?

</comment></comment><comment><USER33> Read the first comment in the page by Isaac Yonemoto it's better than the post.

</comment><comment><USER34> I agree with this.

My problem is that I have a big problem sacrificing my free time for my regular paycheck while the boss makes potentially millions.

<comment><USER35> Hey, that boss isn't taking home a paycheck like you are, so suck it up. <adding sarcasm tag here just in case>

<comment><USER36> Offer your boss to work completely for free in exchange for equity then. I wonder if anyone has tried this and what the response was.

<comment><USER37> Nothing would happen.

I don't know from where this started.

But I am expected to make for somebody Else's lapses all the times. This is called in classic management language 'Team work'. And the managers don't pay you for doing 'Team work' , at best you are assumed to just doing your duty. So you are not supposed to get paid extra.

I know a lot of managers who consider people who ask rewards for extra/free/innovation/<whatever fancy word for making you slog extra for free> work as a evil people.

<comment><USER36> I took the comment about bosses not taking home a paycheck to be referring to a startup scenario where funding is tight and so the founders don't take home a salary while the first few employees do.

In that situation it's not at all uncommon to trade some wage for equity, but there are not many cases that I've heard of, outside of the founders themselves, that are so extreme that people literally take home only equity.

If the discussion is talking about big well established companies, then the situation is very different. I can't imagine many managers not taking home a salary and definitely agree that inequity is generally a big problem as is the expectation of common place unpaid overtime.

<comment><USER35> It's about the startup scenario, because I'm living it.

I'm an early hire and took a pay cut in return for a tiny amount of equity. CEO is in fully and is taking home a _very_ small salary. So every request for a raise is augmented with "well, I'm not making as much as _you_ are".

You can only hear that so many times before the resumes go out.

</comment></comment></comment></comment></comment></comment><comment><USER38> I'd agree I almost never burn out because I workout everyday. I really believe the studies that says fit people are happier because nothing clears my mind like working out or playing basketball especially after a long coding session.</comment>


Ash HN: What are you yelling about wrt Google/Verizon? - <AUTHOR>

From Google's Public Policy Blog, dated Aug. 09:
``Today our [Google and Verizon] CEOs will announce a proposal that we hope will make a constructive contribution to the [net neutrality] dialogue. Our joint proposal takes the form of a suggested legislative framework for consideration by lawmakers, and is laid out here. Below we discuss the seven key elements:
First, both companies have long been proponents of the FCC's current wireline broadband openness principles, which ensure that consumers have access to all legal content on the Internet, and can use what applications, services, and devices they choose. The enforceability of those principles was called into serious question by the recent Comcast court decision. Our proposal would now make those principles fully enforceable at the FCC.
Second, we agree that in addition to these existing principles there should be a new, enforceable prohibition against discriminatory practices. This means that for the first time, wireline broadband providers would not be able to discriminate against or prioritize lawful Internet content, applications or services in a way that causes harm to users or competition.
Importantly, this new nondiscrimination principle includes a presumption against prioritization of Internet traffic - including paid prioritization. So, in addition to not blocking or degrading of Internet content and applications, wireline broadband providers also could not favor particular Internet traffic over other traffic. ''
http://googlepublicpolicy.blogspot.com/search/label/Net%20Neutrality
So what's all of the rhubarb about? <comment><USER2> The main contention is that although this is good news for wireline businesses, the real future growth in data is expected to be wireless, which is given a free pass from the "teeth" of this proposal.

Instead, the idea is just to let people "know" when they are being screwed over, basically, by having a sort of transparency around when things are unfair.

That's the fear, I believe... and the idea that Google has ceded too much in the proposal instead of fighting for the same kinds of provisions in the wireline proposal to exist across all kinds of data channels.</comment>


Qualcomm Maps Out ARM Datacenter Battle Plan - <AUTHOR> http://www.nextplatform.com/2016/02/12/arm-servers-qualcomm-maps-out-datacenter-battle-plan/ <comment><USER2> I do have a horse in this race, but even if I didn't I would say this:

Does Qualcomm, a company which has laid off ~20% of its workforce with even more jumping ship, 48% year over year revenue decline (as well as 44% profit decline, even after layoffs), increasingly difficult time differentiating itself from its competitors (who are in key areas starting to do better than them), really think they are going to be able to quadruple their total earnings in purely through new markets? All in under 4 years? Do they not realize that both their existing market as well the magic "IoT" market that they think will save them has even lower margins and more competition then the market they are in now.

Or since this was an investors meeting, shall we assume Occam's razor and are they just trying to prop up their stock that has dropped to half its value (and still trending downwards) in the midst of internal turmoil and losing marketshare.

<comment><USER3> Not to mention the CPU choice is one of easiest parts of making a datacenter company. I'm not counting heterogenous ones customized to workloads like I've always advocated: just typical put work or VM's on Intel/AMD CPU's. What they need to do, from marketing to operations to internetworking, to outperform major players in datacenters is huge and not in their direct expertise.

I could see them establishing new revenue by making some custom SOC's for host workloads, I/O offloading, and networking analysis. There's already companies and academics in this space but barely tapping the potential. They could bring in some big bucks putting their engineering talent into some already proven methods. Not going to solve their company's problems, though. Too big haha.

<comment><USER4> I thought Xeon-D already solve that SOC problem you mentioned.

AMD's ZEN is the closest to get Intel some competition. The margin on Xeon product line are huge, making plenty of room for AMD to strike. And since the Cloud is still a growing market, I could see Intel lowering price and AMD still enjoying some success in it.

This scenario should make it even harder for Qualcomm, or any ARM maker to set foot in server market.

<comment><USER3> I didn't know about it. Thanks for mention. My baseline for this topic of SOC's w/ offloading is Cavium's Octeon line:

[http://www.cavium.com/OCTEON-III_CN7XXX.html](http://www.cavium.com/OCTEON- III_CN7XXX.html)

The summary should give you an idea. Just offloading TCP/IP or filesystem ops by itself can knock a host CPU down from 90+% utilization to closer to 10%. That leaves a lot of room for compute. Such a situation helps whether the Octeon was the host or a coprocessor for a Xeon host. Now, apply that same principle to text algorithms, concurrency support, compression, SSL, Hadoop's main ops, key mechanisms of deep learning, and so forth. Performance you get per dollar and watt gets crazy.

The only strategy I had that could deliver better was integrating FPGA's with CPU's so workload could be split. Intel is already on top of that with Altera acquisition. I can't wait to see accelerator logic on a Xeon. :) Meanwhile, a combo of multicore CPU and libraries that tap into accelerators is much easier for average developer to use. No hardware design experience necessary.

<comment><USER4> Exactly my thoughts on FPGA, it is going to be huge on server market. Although I read AMD is also working with Xilinx, but unfortunately due to the issue with AMD, they will continue to use GF rather then TSMC which is what Xilinx is using for the forseeable future.</comment></comment></comment></comment></comment>


"Real" OS X Apps on the iPad? Are You Crazy? - <AUTHOR> http://geekfun.com/2010/01/31/real-os-x-apps-on-the-ipad-are-you-crazy/

<comment><USER3> "There are many reasons for this, but it really starts with the fact that modern Macs use Intel CPUs and Intel CPUs just aren't as power efficient for a given level of performance as the ARM CPU in the iPad,"

Doesn't the iPad have an Apple chip now?

Otherwise the article is a fairly nice commentary on why iPad doesn'r run OSX native apps. The article doesn't cover the technical details of what would be required to write an ObjectiveC app that ports to Both platforms. The Developer Tools for iPad is out, and I'd like to hear more about it - <USER2> of course, it IS the _same_ as the iPhone developer tools.

<comment><USER4> Speculation around the 'tubes believe that A4 is a System on Chip based around the core ARM architecture.

</comment></comment><comment><USER5> From a developer's perspective, there's a real possibility that the iPad will be trapped in the valley between cheap, simple iPhone apps and powerful, albeit expensive desktop applications.

The economics of the App Store are already a bit shaky for sophisticated (read expensive) apps. Taking advantage of the iPad certainly won't be less expensive, yet realistically there will be far fewer potential customers even if the iPad is a success.</comment>


The Party's Over for Buffett - <AUTHOR> http://www.nytimes.com/2011/04/30/opinion/30nocera.html?_r=3&ref=opinion <comment><USER2> Here's a direct link to the audit committee report: <http://www.berkshirehathaway.com/news/APR2711.pdf>

The NYT article is inflammatory, makes factual errors, and is even a bit trollish at times. A simple analysis or opinion piece would have been fine.

"Since then, Buffett has been subject to criticism of a kind he has never before faced."

"'It makes you question Warren's judgment,'" - author who happens to have a new Warren Buffet book out.

"What moved him to pre-emptively clear Sokol, who had so clearly violated Berkshire's code of conduct, of wrongdoing? What does that tell us of possible flaws in Buffett's character?"

"He often buys companies with very little due diligence;"

"His board is made up primarily of cronies"

Yeesh

<comment><USER3> "He often buys companies with very little due diligence;" that doesn't sound like Buffet at all. If everyone who bought stock, CDSs, and other complex financial instruments did as much diligence as Buffet everyone in finance would still think a TARP is something you use to protect things from the elements.

</comment></comment><comment><USER4> The article talks as if this one act of misconduct (which we only know about because Buffet announced it) proves that Buffet is always letting stuff like this happen, which frankly there's no evidence of whatsoever.

The _only_ piece of the article that could be used to justify the bait- headline is the fact that he is growing old and can't live for ever - in fact, that was the only statement in there worth making at all.

Not exactly grounbreaking journalism to reveal that a man who is 80 years old won't be able to keep doing his job for the rest of eternity. Frankly, I expect better of the NY Times.

</comment><comment><USER5> That's one overly dramatic title. Buffett has navigated far worse situations in his business career. Look at what he went through with Solomon. That situation actually had the potential to sink his entire company. Buffett may have lost a successor in this case, but it hardly spells the end of him or Berkshire.

<comment><USER6> > Buffett has navigated far worse situations in his business career. Look at > what he went through with Solomon.

Absolutely. Or, to a lesser extent, the Buffalo Courier-Express antitrust case back in the 70s. Buffet's "go honest early" policy is yet another brilliant long term strategy that seems slightly crazy / ruinous in the short run.

For anyone interested, this book was a good read:

[http://www.amazon.com/Buffett-American-Capitalist-Roger- Lowe...](http://www.amazon.com/Buffett-American-Capitalist-Roger- Lowenstein/dp/0385484917)

</comment></comment><comment><USER7> How is the party over? Buffett, later than he probably should have, admitted that Sokol's transgressions were unacceptable, and now Sokol is gone. Ultimately this is not going to have an impact on Berkshire's bottom line or share price. The stock was never really the "darling" of Wall Street because Berkshire never catered to analysts.

</comment><comment><USER8> What a terrible article. The guy got fired! Isn't that sufficient? Buffett has always railed against the ridiculous processes that cripple other companies. Why would or should he behave differently?

<comment><USER5> He wasn't fired, he resigned.

<comment><USER9> Semantics. When your boss asks you to resign, you've been fired.

<comment><USER5> Normally, yeah, it would be semantics. Except in this case Buffett gave the appearance of being soft on the situation up until the audit committee at Berkshire released the damning report against Sokol. I believe this article is drawing the connection between the way Buffett manages and the problems that could create for shareholders down the road.

</comment></comment></comment></comment><comment><USER10> All I got out of this article is that Buffett is kind of old and will probably die someday. I guess that means the party will be over someday, but it's not really newsworthy because pretty much everyone dies.

</comment><comment><USER11> I was at the shareholder's meeting. Several of the initial questions were about the Sokol incident, and many were hostile toward's Buffet's response (especially his initial press release). Buffet answered every question clearly and confidently, tracing his line of reasoning in terms of the information he knew at the time. I don't think the image presented today by Buffet and Munger is consistent with the conclusion that Buffet is reeling from a "serious dent in his pristine image."</comment>


Powerful backdoor found in software used by 100 banks and energy cos - <AUTHOR> https://arstechnica.com/information-technology/2017/08/powerful-backdoor-found-in-software-used-by-100-banks-and-energy-cos/ <comment><USER2> People can say whatever they want, but Kaspersky RE guys are really good.</comment>


Tech firms urge Obama not to give police backdoor access - <AUTHOR> http://rt.com/usa/260113-backdoor-encryption-police-google/

<comment><USER2> Much better headline than WaPo ran on their version of this story.

RT: _Apple, Google and 140+ tech firms urge Obama not to give police 'backdoor' access to encrypted phone data_

WaPo: _Tech giants don't want Obama to give police access to encrypted phone data_

Notice the difference? In WaPo's spin on it, "Tech Giants" (who are automatically unsympathetic as "giants") selfishly, or perhaps criminally, don't want Obama to let the police do their jobs. In RT's spin, "Tech firms", many of them, not just Big Search and Big iStuff, want to keep an overreaching police force from _backdoor_ access.

I'm kind of shocked at US mainstream media's take on all the mass surveillance. Even NPR appears to tacitly approve of all of it because terrorism.</comment>


Examining The Outrageous Aaron Swartz Indictment For Computer Fraud - <AUTHOR> http://www.litigationandtrial.com/2011/07/articles/series/special-comment/aaron-swartz-computer-fraud-indictment/

<comment><USER2> I'm the author of that. It's dated, though to my knowledge none of the issues there have yet been resolved, and the trial is scheduled for February 2013. Seth Finkelstein noted < <http://sethf.com/infothought/blog/archives/001476.html> > that a new indictment has been filed, though it is not, at least in my brief skimming, substantially different, it just fills out the details.

There is a much bigger issue in this case, one that comes up surprisingly often: criminal prosecution for "exceeding authorized access." Should we prosecute people who use online services in violation of their Terms of Service? Of employees who, without installing malicious software, snoop around their networks for stuff they shouldn't be seeing? Is any of that worthy of criminal penalties?

</comment><comment><AUTHOR> Slightly dated, but interesting look at the JSTOR case against Swartz from someone who appears to understand the laws in play.</comment>


Upgrading a Rails 2.1 app to 3.2 (slidedeck) - <AUTHOR> http://derwiki.tumblr.com/post/28038287010/upgrading-a-rails-2-1-app-to-3-2

<comment><USER2> We are precisely in that process, where one of our apps (Ruby 1.8.7+Rails 2.1, originally Ruby<1.8+Rails 1.x) has been forked at some point. Due to various mishaps, the main, generic branch got so rotten that we're simply dropping it and built a brand new version, but the customer-specific, simpler fork is deemed "recoverable" (although there's a good pile of code worthy of TDWTF it's miles better than in the main branch). We're currently cleaning up all the WTFs, "delet[ing] as much code upfront as [we] can", and the next step is dropping 1.8.7 in favor of 1.9.3, and subsequently bump to Rails 3. That's still a long winded road ahead.

<comment><USER3> FWIW, we did this in the opposite order (first Rails 3/3.2, then Ruby 1.9). The bigger wins in developer productivity and access to shiny new toys are to be had by jumping to the latest Rails version. Updating Ruby is just the icing on the cake.

<comment><USER4> Definitely agreed. I'm working on a 1.8.7 site for the last six months, and it's been perfectly workable. Some gems do make the assumption of 1.9, though, which can suck.

(We just upgraded to 1.9.3)

<comment><USER5> I recently dropped all official 1.8.7-support for all my projects. Informally, most of them should still work (tm). 1.8.7 is past its EOL and will only receive security fixes until next year. Not having a migration planned for the near future is reckless.

<comment><USER4> _Not having a migration planned for the near future is reckless._

I'd argue that doing both a Rails 2 -> 3 upgrade at the same time as a Ruby 1.8.7 -> 1.9 upgrade is more reckless. I do agree that it would need to happen damn soon, though, but not concurrently.

</comment></comment></comment></comment></comment><comment><USER6> I've migrated a few large apps to 1.9/3.x, and it's the least fun I've ever had as a developer. The API changes in Rails and the burden they place on developers makes me think twice before using Rails for new projects.

After a while I ended up with a set of Vim macros that handle a lot of the superficial changes, but it's still painful drudgery that makes me wish I was working with a language and framework that's less fickle.

And, be wary of projects with a lot of dependencies and plugins. Think very carefully before adding a single gem to a project.

<comment><USER7> > The API changes in Rails and the burden they place on developers makes me > think twice before using Rails for new projects

you can always switch to PHP - they keep their API stable for years.

Of course everybody equally hates them for that because keeping a stable API also means keeping warts.

So what is the correct way to go? Only fix the API's I'm not using? That would be great for myself, but what about everybody else?

I very much agree with your comment about dependencies though. When you decide to take on a dependency, never decide based on what work it saves you right now - also think about how much work it will be to fix it for the future.

On the other hand, NIH is bad either. It's really hard to find the correct middle-ground.

</comment></comment><comment><USER8> We had the same experience with one of our main Rails apps recently. The original version was written in 2007 in Rails 1.2.x and Ruby 1.8.6. Since then, lots of features have been added, which of course inflated LOC and increased gems/plugins dependency even further. We migrated the app to Rails 3.1 last year with the help of a number of gems that provide backward compatibility. Even though, it took much longer than what we planned. Majority of the files, be it models, controllers or views, had been touched and changed. The worse part was that we didn't have sufficient test suites to assist so lots of manual tests. Along the way, we gradually replaced those obsolete plugins/gems one by one, which was a pain but seemed to be worth it.

Early this year we migrated the app to 1.9.3/3.2.x. Basically the same process but less painful, as most of the gems/plugins issues have been ironed out last year.</comment>


Creating a Dark Mode for Gitlabs Web IDE - <AUTHOR> https://about.gitlab.com/blog/2020/05/20/creating-a-dark-ui-for-gitlabs-web-ide/ <comment><AUTHOR> Our design team at GitLab has been working hard to create a Dark Mode for a first part of our UI, the Web IDE. In this blog post, we have put together some of the challenges, learnings and future plans we have around creating a Dark Mode for the GitLab UI.</comment>


Watch live illustrators and artists on Sywork (YC S15) - <AUTHOR> https://sywork.tv/

<comment><USER2> Hey folks! I'm Marcelo, one of the co-founders. Sywork is a live streaming platform for illustrators and digital artists. It's like Twitch but for artists. It's a place created especially for them.

We've just released our beta. We'd love to hear your feedback and answer any questions!

<comment><USER3> What advantages do artists get for using Sywork instead of Twitch?

<comment><USER4> Twitch is gaming-only, and users can only stream gaming-related subjects.

<comment><USER5> Twitch actually has an entire section titled Creative[0] where people paint, do graphic design, sculpt, etc. Right now there are 2,000+ viewers. They also have sections for Music and Game Development / Programming.

[0] [http://www.twitch.tv/directory/game/Creative](http://www.twitch.tv/directory/game/Creative)

</comment></comment></comment></comment><comment><USER4> It's worth noting that Sywork is (YC S15), which may be why this submission is receiving a lot of upvotes: [http://techcrunch.com/2015/08/05/watching-people- do-stuff-is...](http://techcrunch.com/2015/08/05/watching-people-do-stuff-is- a-business-model-and-sywork-is-the-twitch-for-illustrators/)

EDIT: Was later added to title.

It's also worth noting that the YC S15 batch has another livestreaming startup, Livecoding: [http://techcrunch.com/2015/06/29/yc-backed-livecoding- tv-is-...](http://techcrunch.com/2015/06/29/yc-backed-livecoding-tv-is-the- twitch-tv-for-coding/)

</comment><comment><USER6> This is very exciting to me, especially because visual art doesn't get as much public attention compared to the performing arts. It's perhaps not surprising as we only see the finished products, assuming we even know where to look. Would music get as much hype if there were no live performances, and only straight-to-download albums? The analogy isn't perfect, but lending a live production element to visual art might just make audiences feel more involved.

<comment><USER2> Yep! That's what we think. And you can only see how hard it is to create visual art if you see the process.

</comment></comment><comment><USER7> SUCH a great idea. Is the platform also open to broader art and craft forms (beyond traditional "art") - say quiltmakers or knitters/other fiber artists?

</comment><comment><USER8> Sywork stands for "Show Your Work". Cool!

Are you guys going to introduce software based filter in the future?

<comment><USER2> You're saying something like a content-control software?

<comment><USER9> I think they mean "only watch Illustrator" or "only Photoshop".

<comment><USER8> Yes, this is what I meant.</comment></comment></comment></comment>


Hate Globalization? Then Embrace Stagnation - <AUTHOR> https://www.bloomberg.com/opinion/articles/2019-05-16/hate-globalization-then-embrace-stagnation <comment><USER2> This opinion piece is attempting to point relationship between global trade, offshoring and rising productivity. But even the autor doesn't sound convinced.

I do not deny, it might be true, we will probaly never know for sure as is always the case with laws of economy. But on the other hand offshoring might be seen as some sort of Dutch disease. [1]

Instead of improving productivity the hard way (through R&D, automation, logistics, ..) it allowed business to take the shortcut to greater profits - through moving where production is cheaper.

[1] [https://en.wikipedia.org/wiki/Dutch_disease](https://en.wikipedia.org/wiki/Dutch_disease)

</comment><comment><USER3> > Increased trade and rising productivity – the engine of growth -- go hand in > hand.

As if anyone was against trade or rising productivity on principle. They generally criticize that the bottom X% don't really participate in that rising productivity while the upper Y% participate exponentially more.</comment>


Git pretty - <AUTHOR> http://justinhileman.info/article/git-pretty/ <comment><USER2> Note that this post is five years old (according to the page itself), but it is probably still a good reference.</comment>


Google Wallet launches on the iPhone - <AUTHOR> http://www.theverge.com/2013/9/19/4748390/google-wallet-debuts-on-ios <comment><USER2> Google is taking over Apple!! :-0</comment>


Facebook's role in Brexit, and the threat to democracy - <AUTHOR> https://www.ted.com/talks/carole_cadwalladr_facebook_s_role_in_brexit_and_the_threat_to_democracy?language=de <comment><USER2> I find the subtext of all of these articles and complaints somewhat irritating, even if I am politically aligned along the same "side".

If people vote for this or that populist, then they must have been tricked. If they were better informed, they would surely vote for The Economist-style liberal centrist status quo, right? Sad to see that democracy is dead and that these voters are completely wrong about their own lives, eh?

<comment><USER3> Arguing that power should be distributed and the people's vote respected isn't a route to personal power or success.

Instead we get the pitch: "the people were misled and it's all X's fault, vote for me to curb X's power". Presently, X is facebook or twitter. It used to be Republicans.

</comment></comment><comment><AUTHOR> It's interesting that this video can't be found in full on YouTube. Why do you think that is?</comment>


Ask HN: Startup Living NYC - <AUTHOR>

Startup Living NYC
I just made it to the city with everything I own and version one of my product SureDone - I've got some resources including http://www.linkedlistnyc.org , http://www.generalassemb.ly , http://startupdigest.com/new-york-city/ , and http://wiki.coworking.info/w/page/16583629/CoworkingNewYorkCity  to keep one busy for time to come.
I'm looking for startup centric living resources like startup housing or targeted  communities. Low rent options to give time for new resident me to establish a home. Cheap safe places to sleep in the city at night would be of most help.
I came here to make friends, win peers, trade labor, and build internet business, win or die...
Any help is greatly appreciated. <comment><USER2> Someone was trying to start a "targeted community" for startups a while ago on Kickstarter or something, but I think it fell through. I can't think of any existing ones currently. Most startups are centered along Broadway from 14th st to about 30th st, and within a block or two of that east or west, but don't be fooled into thinking you need to live in that neighborhood as well. I'm out in Bushwick, and it still only takes me about 25 minutes to get to Union Square.

Low rent - in general, aim for something off the L train from Graham Ave to Jefferson Street, or on the Q/any of the other express trains in south Brooklyn. Get a roommate. ASAP. Living alone is another 300-500 per month at least. You can get a room in the 20-30 minute commute range in Brooklyn for maybe $600-800 a month, plus your share of utilities. I've seen people get these prices in Manhattan as well but its harder to find - check Kip's Bay area or Upper East Side from 80th-100th streets.

<comment><AUTHOR> Thanks big help! If you know anyone needing roommate ASAP my email is my username at gmail.com . Strategically I'm thinking storage unit in the city, gym membership keeps me fit and clean each day, and bed at night just to sleep. I know PHP MYSQL JQUERY HTML CSS UBUNTU SERVER and more full stack I can trade for any help getting established here.

<comment><USER2> If you're looking to be frugal and think you need a storage unit and a gym membership, you're doing it wrong.

Also, eating out in NYC will kill your wallet. Hope there's a kitchen next to that bed.

<comment><AUTHOR> I'm only thinking storage @ 50 per month access to my things without a place ASAP, gym gets me shower and even locker/ laundry service for extra 60 per month. 5 dollar sub per day no more at first. With no network yet I'm hoping for luck finding a place.

</comment></comment></comment></comment><comment><USER3> FWIW, I tried to search HN for resources because it seems to me this type question (or something similar) has come up before (but with no real support from what I found: <http://news.ycombinator.com/item?id=2849930> ). I did find this article in the process and thought I would pass it along:

[http://www.mikekarnj.com/blog/2009/12/21/new-york-startup- mo...](http://www.mikekarnj.com/blog/2009/12/21/new-york-startup-movement/)

And the discussion that went with it, for whatever it's worth: <http://news.ycombinator.com/item?id=1008080>

I know that's thin. I am only posting it because you seem to not be getting much response. Otherwise, I wouldn't waste your time.

Best of luck.</comment>


Why everyone hates MongoDB - <AUTHOR> http://gustavoveloso.posterous.com/why-everyone-hates-mongodb <comment><USER2> Because it's not a particularly good database, but it's being marketed strongly.

There are better (more mature, easier to maintain, faster, etc.) alternatives for both single-machine (Postgres, MySQL) and distributed (Cassandra, HBase) usage.

It's a pain to take care of, it does table scans all the time (partly because it has no schema, partly because of design issues), it has pretty poor profiling tools. It's almost impossible to use without a model/schema in the app. Migrations are a pain.

The one thing it's particularly well suited at is indexing and searching JSON- like data.

<comment><USER3> You are making sweeping (but vague) negative characterizations of a technology while, at the same time, accusing the company that created the technology of marketing it strongly.

When DHH created Rails, was it his job to tell you all the reasons why you should not use it over Java/.NET/PHP or, instead, to tell you all the reasons that he created it and the problems that he was trying to solve by developing apps with it?

To say that there are better alternatives implies that you understand everyone's use case. It is faulty logic. One of the reasons for the revolt that was "NoSQL" was an attempt to get people to stop shoe-horning data into MySQL ... so the concept of developers using database engines poorly isn't new. Same with MongoDB and developers that use it based on their experiences with MySQL or other relational (or non-relational) models.

I have seen people use MongoDB to great (even amazing) success and have seen others use it very poorly. In both cases, it was the developer (and not the technology) that was responsible for the way they used the technology.

<comment><USER4> There is something to be said for well architected software independent of any features that one may find attractive in it. For databases this is a big problem as you often don't find out about technical problems until you are already committed to the technology and are trying to scale it.

The same thing happened with MySQL and now it looks like it is happening with MongoDB as well. Mongo has so many corner cases and although I have never scaled it up in production the amount of moving pieces and the clear lack of attention paid to distributed programming literature in the design doesn't inspire a lot of confidence.

Technical problems with MongoDB are being explained away as features in the same way MySQL did. Why does Mongo MMAP its datafiles?? So the cache stays warm!!! Why doesn't MySQL have transactions? No one needs transactions, just lock the table !!

If you didn't consider these cases you might think that Mongo sounded pretty good. I don't fault 10gen for pushing this hard and taking advantage of the perception that NoSQL is a more modern technology. I just can't believe there isn't something better that does what Mongo does.

<comment><USER2> RethinkDB looks to be a better Mongo. It even does MVCC, the lack of which I certainly felt with Mongo (can't do analytics queries on your data or build indexes without DoS-ing your db).

<comment><USER5> We also don't mmap the data files, though it's much more relevant to the internal architecture than user facing features :)

</comment></comment></comment></comment></comment><comment><USER6> I've made a transcription of the famous 'MongoDB is web scale' video, a humorous conversation between a NoSQL fanboy and a more cautious, conventional database developer:

 _"'And in conclusion, we have found MySQL to be an excellent database for our website. Any questions?'

Yes, I have a question. Why didn't you use MongoDB? MongoDB is a web scale database, and doesn't use SQL or JOINs, so it's high-performance. ...."_

Read the entire conversation at <http://www.mongodb-is-web-scale.com/>

<comment><USER7> That was pretty funny. Thanks.

</comment></comment><comment><USER8> The plain answer is it's painful using newer technologies. If you use node.js and mongoDB be prepared for working without a net and stumbling across errors that no one has encountered before as it comes to fruition. Be prepared for putting a question out to the community and hearing nothing back. But honestly I've seen the same thing with almost every technology at the beginning of it's life span. If you are a pioneer recognize it and plan accordingly.

And if you just chose it willy-nilly because it's a hot tech, well.. You made a mistake.

PS - linking to a couple paragraph blog with come conjecture and a link to a google search? That deserves a bitch slap. Try harder.

</comment><comment><USER9> There's no content in that article other than a link to a google search for "why mongodb is bad".

<comment><USER10> I'm not sure what the intent of the article is.

However, we can see that it has again sparked the age old flame war. It reminds me of the online flamewars that start once someone voices their opinion on some hot topic like mac vs pc, ios vs android, etc.

</comment></comment><comment><USER11> It's cool to hate MongoDB, it used to be really cool to like MongoDB. Same thing happend with MySQL probably 10 years ago. I have built some apps with Mongo and it's fine as long as you don't expect it to be a SQL database. A lot of times I wish it had features x,y,z from sql land, and other times I wish MySQL was schemaless.

Nowadays, I have begun to defer my database choice until I absolutely have to put an app into production if possible. That way I can write an app and have it working without worrying too much about queries, caching, and so on until I need to actually put it out on a real server.

MySQL, Mongo, HBase, Cassandra, Postgres, Riak, Redis, Memcache, Couchbase, Filesystem? It doesn't matter.

They're all going to break at different times for different reasons depending on how you use them and what scale you are at. Everything breaks at scale eventually.

Build something awesome enough that it breaks under the user load. That's a good problem to have.

<comment><USER12> _It's cool to hate MongoDB_

When a product is pushed as essentially a silver-bullet -- often by people who have never and will never actually build anything with it -- it is naturally going to get a lot of backlash by people who see through the problems, and moreso by those who _buy_ the hype and then smash into the reality halfway through their projects.

I speak from personal experience on the first point, while the second has come from countless real-world case studies. A couple of years back I had several widely distributed pieces declared "trolls" because I essentially called for a sobering reset on the NoSQL hype train. Every single thing I said has been well proven out since, so there's that.

<comment><USER13> Then that's obviously a problem with the people touting MongoDB. It's not an inherent fault in the actual software itself...

<comment><USER12> Absolutely and unequivocally true! And the truth is that the actual makers have always been quite reasonable in their claims. But from an industry perspective it is hard to separate the two, much like Visual Basic got most of its bad rap from the _people who used Visual Basic_ than from the platform itself.

</comment></comment></comment></comment><comment><USER14> The reason why I dislike MongoDB is because it exist in between that key+value store and ful blown database. They market is as the best of both worlds, but it ends up being the wost of each world. Its like all those car+bike, car+boat, car+plane, boat+plane, boat+bike combinations that have been marketed over the years.

If I had a bunch of keys and values, I'd put it in memcache. If I had relational data, I'd put it in postgres. I don't see where mongo fits into play. Every time I've seen it used in production, it always seems like its being used as an improperly implemented RDBMS or an improperly implemented key+value store.

</comment><comment><USER15> I'll give the reasons why I hate it, and they have nothing to do with it not being a "good fit" for our model or abstraction problems or anything of that nature. The problem we have with it is that it's an absolute pain to maintain in a large production.

The setup alone is just bizarre, for each replica set you have to have 3 (and only 3!) config server instances associated with your set, along with possibly an "arbiter" instance depending on what circumstances you're operating under. I could do a whole rant (and have, in the past, to anyone who would listen) on the arbiter/voting system mongo uses. We've been left in a situation in the past where one of our secondaries randomly died (more on these lovely "random occurences" later), leaving the cluster with a master and an arbiter left over. Mongo decided that since there was an even number of votes (and why is my production-critical database voting on things?!) it couldn't promote a master (even though the master never actually died), dropped the master down to being read-only, leaving us completely boned. They have since fixed this issue (I think), but it definitely garnered a lot of ill-will from me, and should never EVER have even been a problem.

"Random occurrences" have always plagued us with mongo. Whether it's been random segfaults (less common with more recent versions, but oh dear god were they frequent pre-2.0), secondaries being promoted to master with no clear reason as to what sparked this (which has left us flailing twice now, when a master decided to step down while one secondary was in RECOVERING mode and the other was AWOL), config servers getting out of sync (one time one of the config server sets decided it was going to start hosting the config for an entirely different replica set, luckily no production mongos instances had to reload the config before we noticed), mongos instances getting out of sync/crashing (less common now than before, thankfully), and I'm sure much more that I'm not thinking of now.

To make all of the above about 10x worse the mongo logs are terrible. There is no distinction between INFO messages and ERROR messages in the logs, so everything has to be treated as an error of some kind. And there are many "errors" that we should "just ignore". This makes debugging pretty much impossible. Another nice feature is when you restart a mongos instance (and possibly a mongod instance too, although I could be wrong on that) all the logs from the old process get clobbered by the new one (so backup those logs folks!). It's extremely difficult to track down why slow queries are happening unless you can catch them in the act, and even then it's not trivial.

Mongo has many great qualities. It's one of the few (if the only, that I know of) that can do many of the things that it does, and for that it's very useful. But for it to have been marketed as a production-ready database was a bit disingenuous I think. It scales OK. Not well, just OK. You can make it scale if you try real hard and tiptoe around it so you don't wake it up and make it cry. I think someday in the future all of these issues will be fixed, but at the moment I don't recommend anyone use mongo for anything they plan on a significant number (200k+ users at any given moment) of users being dependent on.

<comment><USER3> Interesting feedback ... I agree on the log messages that look terrifying yet, when googled, are like "oh, that's normal, don't worry about that." I also agree that the 2.x versions of MongoDB have been a great step forward for stability and performance.

On the logging, not sure what you mean by the old logs get clobbered. Is this, perhaps, some house-cleaning job that you have on your server? When we stop/start processes, the logs are appended and keep going.

On the issues with primary/secondary and state changes, do you host your databases on Amazon? We have often found that when we have this issue, it was pinpointed back to some temporary intra-zone networking glitch with AWS ... either with their name resolution or a blip in one zone being unable to see another zone in the window of time that MongoDB has set for the response.

These often (if not all the time) go unreported by AWS until you get them to dig a bit and report back. We effectively utilize priority to keep the member we want as primary and if a state change does occur, it moves back once the full set is healthy again.

<comment><USER15> >On the logging, not sure what you mean by the old logs get clobbered.

For us the logs are not opened in append-mode, just write. We don't do any house cleaning except for logrotate, but that only runs nightly and isn't the cause of what we're seeing. Like I said, it may not be for the normal mongod instance, but it's definitely true for mongos. I'll double-check on the version number of what we're running

> do you host your databases on Amazon?

Nope, all owned servers, over a local network on a switch we own as well. The switching happens on some clusters more then others, so it's possibly a usage related thing.

</comment></comment></comment><comment><USER16> I wonder if the ease of use of MongoDB might be part of why this "hating on mongo" trend exists -- it's very easy to setup and use without having to think through exactly what the best way to use it is. Which means it's very easy to do something dumb without realizing you're doing something dumb. The problem is, most of these database anti-patterns aren't visible at a small-scale, they only become obvious once the datasets get large and then it's really hard to change things.

Pretty much any database is going to leak abstractions at some point, there's absolutely no way of getting around understanding how your DB works. I think the problem with Mongo is that it's so developer friendly initially, that it makes it easy to avoid a lot of hard decisions that will eventually have to be made, and when those decisions do come to the forefront, it's often at a much less convenient juncture in the application's lifecycle to change things.

<comment><USER17> I heard its going to be bundled with the next Flash IDE and support Actionscript for querying.

</comment></comment><comment><USER18> I'm considering using MongoDB for some limited cases in our app:

1\. A capped collection of responses from a 3rd party endpoint (XML) that we often want to go back up to 2 weeks and have a look at.

2\. Data that is all reads after initial write: Historical data, lots of it (100-150M rows and growing fast), that we want to take advantage of the scaleout nature of MongoDB to handle.

3\. "Built out data": Data that is the summarized output of the ground truth in our MySQL DB that is expensive to compute, has a varying JSON schema, and we want have ready at our fingertips for the frontend.

It seems like MongoDB is well suited for these use cases, leaving our transactional and user data in MySQL.

Am I crazy? Should I be considering one of the alternatives instead?

<comment><USER19> As an alternative for 1) you might consider using the TTL collections feature in mongo, which expires data after a given time threshold: <http://docs.mongodb.org/manual/tutorial/expire-data/>

</comment></comment><comment><USER20> I'm not going to argue about the technology itself, but 10gen does provide excellent documentation, screencasts, and tutorials. Other DB vendors could learn a thing or two about writing better documentation and educational materials. Look at <https://education.10gen.com/> and <http://www.10gen.com/presentations> for example.

<comment><AUTHOR> Great point! 10gen is growing really really fast (and receiving a lot of funding to sustain that). The newly-released Education channel is great.

And I really didn't understand other people complaining about 10gen marketing capabilities ;)

</comment></comment><comment><USER21> The thing that pissed me off about MongoDB was finding it in an environment where it had no business being because it had been heavily marketed as 'cool!' 'saves time!', 'web scale!', and so on.

Besides antirez being a friend, I think something like redis more credible due to the fact that it seems fairly clear about what it is, and what it is not.

</comment><comment><USER22> "Everyone" may be a bit of hyperbole. I have some particular use cases where it works really well, and others where I wouldn't dream of deploying it. Using any technology "because it's cool" without understanding the implications only works for experimental stuff where that's the whole point.

</comment><comment><USER23> It's clear that the easiest way to get to the top of hacker news is to discuss why you hate MongoDB <http://blog.serverdensity.com/does-everyone-hate- mongodb/>

</comment><comment><USER24> There's an old saying, "If all you have is a hammer, everything else looks like a nail." People hate MongoDB because its makers (and, to a lesser extent, userbase) actively market it as the hammer.

<comment><USER25> The problem is not that MongoDB is marketed as a hammer, the problem is that the use case most users have is a screw. I think it is a perception problem among developers who have run into problems scaling apps based on relational databases (read: the screwdriver) that they can just drop in MongoDB and scale away. The problem is that MongoDB isn't a better screwdriver, it is a hammer. If you can rework your app to take advantage of a different database structure (read: nails), then MongoDB could be the right tool to use.</comment></comment>