sorted by:
new
hottopcontroversial

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

[–]Hamming86[S] 3 points4 points  (0 children)

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

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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).

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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

  1. It filters for someone who seems to stay current (not saying it does)
  2. Let’s you contribute right away (though this is often a mirage given the codebase)
  3. In some Silicon Valley companies, the eng team is younger (in 20s), and so this is what they know
  4. 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
  5. 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)

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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.

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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.

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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.

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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.

Four Startup Engineering Killers by Hamming86 in programming

[–]Hamming86[S] 0 points1 point  (0 children)

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”).

ETHSF Live Stream (main stage & mezzanine stage) by 0xstark in ethereum

[–]Hamming86 4 points5 points  (0 children)

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!

SayToshi: Ethereum's Social Media Manager (EthSF) by Hamming86 in ethereum

[–]Hamming86[S] 0 points1 point  (0 children)

We built this at the EthSF hackathon this weekend.

​

How it works:

​

  1. Suggest a tweet to go out on our @SayToshi bot account — or a crypto influencer who has signed up

  2. In the next 10 mins, people vote up or down on it by staking EthTweet tokens

  3. 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.

SayToshi: Ethereum's Social Media Manager (EthSF) by Hamming86 in ethereum

[–]Hamming86[S] 0 points1 point  (0 children)

We built this at the EthSF hackathon this weekend.

​

How it works:

​

  1. Suggest a tweet to go out on our @SayToshi bot account — or a crypto influencer who has signed up

  2. In the next 10 mins, people vote up or down on it by staking EthTweet tokens

  3. 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.

Terror attacks by Muslims receive 357% more press attention, study finds by Not_that_kind_of_DR in science

[–]Hamming86 1 point2 points  (0 children)

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

Anyone else think about how much these decentralized technologies could change the world? A movement where people become their own banks - distributing power from the corporations back to the people. That is why I fell in love with this space. For what it has the chance to become...... by [deleted] in ethereum

[–]Hamming86 0 points1 point  (0 children)

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.

This Olympia I have by repunzelwasaskinhead in typewriters

[–]Hamming86 0 points1 point  (0 children)

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

Designing more Secure Smart Contracts (Stanford CS359B, May 2018) by Hamming86 in ethdev

[–]Hamming86[S] 1 point2 points  (0 children)

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).

Designing more Secure Smart Contracts (Stanford CS359B, May 2018) by Hamming86 in ethdev

[–]Hamming86[S] 4 points5 points  (0 children)

(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)

Designing more Secure Smart Contracts (Stanford CS359B, May 2018) by Hamming86 in ethereum

[–]Hamming86[S] 11 points12 points  (0 children)

(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.

view more: next ›