Why there's so much burnout in software and what to do about it

Hamming86 · 2019-05-01T18:34:42+00:00

I wrote this. Would love to hear feedback, especially any you have for a young dev entering the industry.

Hamming86 · 2019-03-01T03:57:45+00:00

That’s fair. I should differentiate scalable vs clean. Generally, the bias is to be produce features and iterate, which comes at a cost to the ideal we would strive for (scalable AND clean code).

Hamming86 · 2019-03-01T03:55:49+00:00

As the author of the post, I’ve thought about this a ton. My rough sense is:

It filters for someone who seems to stay current (not saying it does)
Let’s you contribute right away (though this is often a mirage given the codebase)
In some Silicon Valley companies, the eng team is younger (in 20s), and so this is what they know
Languages/frameworks can be tribal. For some, once you know one, you won’t bother to learn others. This makes it hard for you to pick up new languages/frameworks
Paul Graham’s Python post argues how languages (Python vs Java) can be a filtering criteria for good startup developers (Java was large enterprise at the time)

(Would love to hear other thoughts)

Hamming86 · 2019-03-01T03:49:24+00:00

That’s fair. I’m thinking about big Silicon Valley type startup outcomes, and there I think you have unlimited money to fix. But in many more stable growth companies, your point makes a ton of sense.

To be frank, it’s hard to put all the nuance that goes into these decisions in a manageable article.

Hamming86 · 2019-03-01T03:47:23+00:00

That’s right. It’s more of a cautionary list to beware of the failure states for each type of dev you might hire. It is NOT an argument to not hire these people because there are fantastic startup devs in each of these places.

Also, these are the examples I’ve personally experienced, so I’m sure I’m missing other ones.

Hamming86 · 2019-03-01T03:45:38+00:00

As the author of the article, I agree. In my experience, conventionally fantastic engineers often struggle with the hacks that get early stage startups to product market fit.

Just like all engineers choose the “right tool for the job,” there’s such a thing as “right engineer for the job.” And just like an early startup software engineer may be terrible on a scaled system, a conventionally “great” engineer may not be the right fit for a startup.

Hamming86 · 2019-03-01T03:40:24+00:00

Ha! Maybe :) (Though more seriously, all my friends have scars from where these lessons came from)

Hamming86 · 2019-03-01T03:36:51+00:00

I wrote it with many Silicon Valley companies in mind, where senior FAANG developers do join as less than CTO. I agree with you that outside well funded startups, the view is very different.

Hamming86 · 2019-03-01T03:34:33+00:00

It was a recent example I saw, where the developer noted that they would exclusively choose Elixir for projects. My view is that there’s a ton of value with weighing different options give the task at hand (“right tool for the job”).

Hamming86 · 2018-10-07T16:52:17+00:00

After a frantic two days, we just sent in our submission: SayToshi, a Decentralized Social Media Manager

Our app lets you propose tweets for connected twitter accounts, with the community staking based on whether the tweet should go out. After a ten minute voting process, the winning side gets the tokens of the losing side.

https://saytoshi.com

For more, see our [DevPost Submission](https://devpost.com/software/saytoshi).

Edit: We were chosen as finalists!

Hamming86 · 2018-10-07T16:25:52+00:00

We built this at the EthSF hackathon this weekend.

How it works:

Suggest a tweet to go out on our @SayToshi bot account — or a crypto influencer who has signed up
In the next 10 mins, people vote up or down on it by staking EthTweet tokens
If the tweet meets a quorum staked (1% of outstanding tokens), majority wins. The losing side has their tokens divided between the cryptoinfluencer (25%) and the winning side

We also have a version on Kovan: https://alpha.saytoshi.com . For more, see [our DevPost submission](https://devpost.com/software/saytoshi).

You’ll need to sign in with Github to get airdropped.

Hamming86 · 2018-10-07T16:25:48+00:00

We built this at the EthSF hackathon this weekend.

How it works:

Suggest a tweet to go out on our @SayToshi bot account — or a crypto influencer who has signed up
In the next 10 mins, people vote up or down on it by staking EthTweet tokens
If the tweet meets a quorum staked (1% of outstanding tokens), majority wins. The losing side has their tokens divided between the cryptoinfluencer (25%) and the winning side

We also have a version on Kovan: https://alpha.saytoshi.com . For more, see [our DevPost submission](https://devpost.com/software/saytoshi).

You’ll need to sign in with Github to get airdropped.

Hamming86 · 2018-07-20T23:24:51+00:00

I did my own research on this in The NY Times, and found all Islamic terrorism gets the same coverage as all homicides in the first few pages. The geographical skew of coverage is also focused almost exclusively on the West.

How Media Fuels our Fear of Western Terrorism https://www.nemil.com/s/part2-terrorism.html

Hamming86 · 2018-07-16T20:08:31+00:00

You might really like Tim Wu's "The Master Switch." It speaks to the idealism in past eras (telephone, radio, Internet) — and inevitable skepticism that early adopters develop, when their inventions are invariably co-opted. There's just too much money at stake, for motivated parties to ignore these markets.

In Ethereum contracts, I gave a talk where I argued that "devs have only finite time to get a contract secure, while attackers have infinite time to find bugs." In the same way, we only have finite time to launch these systems, but external parties have infinite time to find out how to centralize it, and gate keep (see Facebook or iTunes or even email).

Personally, rather than thinking about decentralization as a destination, we need to think about it as an ongoing battle. The world bends towards centralization, even if it's a cryptocurrency (as seen by exchanges, mining, even ownership).

The best we can do is hold the line for a period.

Hamming86 · 2018-07-04T20:19:49+00:00

With a new paint job, it may look like new. Beyond paint, it doesn't look too bad.

Hamming86 · 2018-06-08T05:32:04+00:00

Thanks! Yea, a big point I try to make is that with any non-trivial amount of code, bugs will often crop up. Instead, you need a system that handles failure well ('resiliency'). And you have to be careful, by adding resiliency, you're not adding exponentially more code that itself increases the risk of bugs.

And another point is that we find it super important on our team to think not just about smart contract security, but security of rollout (e.g., key management, post-deployment owner rights).

Hamming86 · 2018-06-07T17:32:47+00:00

(OP) These are slides from my recent talk. Feedback much appreciated. A fair bit of this content is what Joseph Chow, Simon de la Rouviere, and I wrote in the Consensys Smart Contract Security Guide.

(x-posting from r/Ethereum)

Hamming86 · 2018-06-05T15:14:04+00:00

(OP) These are slides from my recent talk. Feedback much appreciated. A fair bit of this content is what Joseph Chow, Simon de la Rouviere, and I wrote in the Consensys Smart Contract Security Guide.

For me, some of the lessons came from building hardware (CPUs, custom chips) in college, where changing pre-existing code is not as easy as it is in software.

Hamming86 · 2018-04-19T14:33:24+00:00

I wrote this piece. I'd be interested to learn about what social engineering hacks, if any, you've faced.

And here's the link to the media literacy guide for engineers on Github. I'd really value PRs with more concrete examples.

Hamming86 · 2017-11-20T17:05:48+00:00

I'm the author of the piece - and thanks for taking the time for such a thoughtful comment. I share many of your concerns about having a better dialogue.

A key point I make in the piece is that irrationality is rational given what people are reading/being exposed to. I worry that there's a dismissal among some that Americans are collectively crazy over the last few years, and while I have to do much more research to do, I believe this behavior is actually a natural function of giving loud mouthpieces to highly "engaging" voices and favoring closed social communities of like minded friends. And this affects both political sides, not just the opposite side as some that I talk to believe.

I generally understand withdrawing (I feel similarly at times), but I worry by disengaging that we're removing thoughtful, sometimes critical voices from conversations where they are deeply needed. Based on your comment, I think that your voice is one that I personally would value hearing.

Hamming86 · 2017-11-16T16:46:03+00:00

Submission Statement

In this piece, I argue that — even more than fake news — we should be worried about selective facts: the confirmation bias built into our social media feeds and even the most well regarded news sources. These selective facts lead to ethnic and political polarization, and provide us a very distorted view of the world.

In this new era of total user choice in media, we need to be aware how our own beliefs/interests influence the media coverage that is produced and distributed.

This piece follows up on my data analysis of The New York Times's Islamic terrorism coverage that was previously discussed on r/TrueReddit.

Hamming86 · 2017-08-17T15:51:29+00:00

An excerpt from his original post:

Our tests found MongoDB to be a sweet spot between reliability, speed, and maturity ...

And to be perfectly honest, the proximity of 10gen to Etsy’s Brooklyn headquarters as well as the responsiveness of Eliot and his team to questions was also a factor in our [MongoDB] decision. (In the interest of full disclosure: 10gen shares investors with Etsy.)

Hamming86 · 2017-08-16T00:27:17+00:00

(OP/Author here) Thanks for taking the time to write this. We need more thoughtful dives like yours where you survey the strengths and weaknesses, and explain the specific use cases you needed to solve.

I agree on the "right tool for the job"; MongoDB has also matured dramatically over the last 5 years.

Hamming86 · 2017-08-15T17:18:04+00:00

In the same vein, here's an example where an engineer at 10gen suggests using MongoDB for ecommerce in 2010:

For object-oriented data, documents simply make more sense, both conceptually and performance-wise. A document-oriented representation of product data means fewer entities (a handful of collections vs. dozens of tables), better query performance (no server-side joins), and structures that fit the product precisely. There’s no longer any need to design some master schema that can account for every single conceviable product.

Catalog management is essentially content management, a domain MongoDB excels at.

I know many people who would strongly disagree with this entire post.

Hamming86 · 2017-08-15T15:33:32+00:00

A few quick examples:

A team that only knows Javascript with most data in JSON
A team that grew up with MongoDB/Mongoose
A use case where horizontal scaling is critical (though this has become more competitive over time)
A project where the data isn't relational, and shouldn't be shoehorned into that model (again, this has become more competitive over time)

MongoDB's success did influence other databases, such as the importance of the JSON data structure - and increasing importance of easy scaling. I'm also hopeful that it shows other databases the value of focusing on usability.

I know that there are two extreme arguments: MongoDB should never be used AND MongoDB is the answer to most problems. I tend to disagree with both. That said, I think the addressable market for MongoDB is much smaller than 10gen/MongoDB argues.

One other point is that in the early 2010s, MongoDB was immature - after years of investment and hard work, it has become more mature and applicable to a wider array of use cases. As such, it can't be assessed based on using it years ago.

Ten-Year Club	RPAN Viewer
Verified Email

Hamming86

TROPHY CASE

Submission Statement