mpdehaan2

Missing lots of context.

(A) See profile. These are a lot of skills I HAVE picked up (B) I'm pretty non-technical these days. (C) when I'm suggesting hard work is hard work, I include everyone putting in hard effort - not just developers, but I do lean heavily in endorsing those who build the product.

I'm not saying I can run Goldman Sachs. I can run a few software companies a lot better than they are being run.

What I'm saying here is that CEOs are mortal. The more you know the more you know this. If you're just starting out you may not realize this, but as you start to experience various executives and know the decisions they make, and what the people under them do, with the experience over time - you just see the value that people should be valued more equally and the system should be fixed. To do this, we need the support of everyone in at least knowing the system is broken, not the defense of the broken system.

I am not a programmer these days. Hard work is hard work, and is mostly measured by the stress it inflicts on you. With practice, things get easier. But all people have value.

I wish this were true. A lot of software developers put in this much time due to abusive working conditions and still net poorly.

Even if it were true, there would be no valid argument for $1M/year vs $60M/year differentials.

In startups, folks are doing this for programmer-level salaries.

CEOs are still finding time for some family time - maybe not a lot, but there are a lot of people under the grindstone feeling the exact same problems making low software developer and manager wages.

There can be a lot of spin in CEO exits. Connections made in even a failed position can be used to gain ability to acquire investment or useful position in other companies. Extreme networking value.

Again, the obscene compensation exceeds the risk. Even going back to a VP position somewhere is still lucrative.

I'll disagree with this. If you are in a position where you make $10M a year, you could effectively not work for 20 years and be completely fine. By the time they've done this for a few years, they have obscene levels of wealth and no risk.

There are also the golden parachutes.

With a few exceptions, a "10x" programmer is in most companies making maybe 1.5x than other people his age, possibly quite less.

This may be an extra $50k in some places.

I have not met a 100x programmer, but there are many people who lead important projects (say Linus, Guido, etc). They also do not deserve 100x a standard programmer salary if they were employed at a corporation either :)

Why should we be past it? Because new employees are generally ok with this perception, we do not IMPROVE the perception, and we allow things to continue.

I've seen quite a few CEOs of companies I've worked at where most of the employees could make a lot better decisions. You probably have as well.

These "people in the drivers seat" are often not very good drivers. Some are. Most are terrible, and while the company (the collective of all the people working there) may be making "huge value", it is by no means certain that it could not be making 100x more - and sharing it better with the people underneath.

CEOs are just humans, like you, who happen to be leading something. They do not have magic brainpower skills.

While that is true, they often suck too. Goes both ways.

Think about how much better, say, Cisco could be, than what Cisco is. And then what their execs get paid. There's a club at the top and they value weird things.

One employee's work can also make a company millions - I know in many cases many of my fellow developers have built things, often single-handed, that have made companies millions, and received less than $100k/year. The sales guy probably got a huge commission.

This is the system we should - as best we can - press against.

In my case, I CAN do their job. They have a lot of support structures to delegate between. You may think you can't do their job, but you could, if you wanted - though getting there is a game of thrones of sorts, and you may not wish to play.

However, they can't do your job. Assuming you are a developer, they are making a living based on your work. Your work has equal value. Well, if you ARE doing hard work. If you are just sitting at a terminal, more ambition might be a good thing :) Cultivate it and you can get there. If you want.

We need not assume all leadership at the top is steering the entire ship, more so than steering parts of things, decisions trickling up as well as down, alongside information.

Exercise++

My take-away from exercises was more of that it builds awareness that makes it easier to stay in flow states for longer over time, which in turn allows (like he says) kind of not making thoughts go away but getting less attached to them, also over time. It's definitely not an immediate gain, but I think the "noticing you are being distracted" and being able to stop is a good part.

Clearly it does not. However, it should.

I could probably do a better job - many people here could. However one of the perks of getting out of the corporate game is getting out of the corporate game.

Excellent points in this article - another factor is they are often paid outrageous base salaries (plus options) for the success of a company, when the success of that company can often be in spite of the CEO, coming from within, and embodied equally by all of the collective employees.

Executive comp is a major racket, enforced by the standard that this is "what the market average is". Which is set by executives overpaying themselves.

Ask yourself if your CEO is really working 100x as hard as you, or 100x smarter than you. The answer is usually a definite no. I'd really like to see more fair pay in this area and a culture that treats contributions of all employees more equally.

Somewhat off topic, but if you are having anxiety issues, I strongly recommend the Headspace mobile app. While a lot of mindfulness apps have a lot of fluffy new-age tone to them, this one did not, and it also tends to introduce concepts at a very good pace (a little bit of things to try each day) which makes things memorable. By contrast, you may talk to someone and hear 100 things to do, and you'll explode trying to do them all.

Anyway, for me, it strikes the right balance. The trick here is more about learning to focus but also learning to completely percieve the feeling and know what it is, and then it's less strong than trying to always think about it - rather than identifying with it.

Programming architecture/problems in SC, yes.

I think Pokemon scaled remarkably better than any app many of us have ever dealt with, seeing the crazy demand spikes. You would run into a lot of app issues, data choices, a lot of things that don't just get solved from simple uses of autoscaling.

I've done this (and successfully exited a startup) and I think you should wait. A bit.

Startups generally take a lot of capital, and you do want to make sure you are building up to some level of savings. If you can do something as a side project and have it grow to start making money, that is super great - though be prepared that there is some risk in terms of seeking outside investment (and that this also takes a large amount of effort).

As such, work in a couple of startups as well as at least a medium size company (several hundred people or so) and get a feel for how they do business. Learn what works and what doesn't.

Finally if you do decide to go through with it, be aware your life and company are going to pretty much merge, which can be more mentally challenging than I can prepare anyone for - which will affect you even after you're done with everything.

I think the most important skill you need to learn is instinct, which comes from seeing a lot of things happen in both good ways and bad ways.

Keep your idealism - build amazing side projects, hone your craft and have fun. There is no timer that says you have to start something only in your 20s and software development in the wild is a lot more different than college.

Keep those ideas going, but don't feel rushed if you don't want to do something right away.

Try to find some cool startups to work for, and learn from them. That may be enough for you creatively. If you still think you have some revolutionary idea, go for it. But don't approach it as "I want to do a startup", you should have some idea that you really really like and want to do for a very long amount of time, and have a lot of ideas around.

A lot of the attempts to start startups fail because the idea is principally around "I think this could make money" because we glamorize startups, when we should look at many of them as just risky ventures between a handful of people.

That's ok, but you need to eat. And you need to have hobbies and live your life too.

There's plenty of time.

Hmm, IDK.

Stuff like @attr.ib is kind of cute looking. (This not being a good thing).

Though in reality, I'd probably want more explicit methods. If you are using something like Django REST framework, you can validate with the serializer. And sometimes you want to validate (often) the combination of variables and how they interact.

Kind of feels a little non-pythonic to me. Clever, but the ways it is changing things are stuff you have to unroll if the behavior grows, versus stuff you just add to.

Yeah I don't think there's a reason to perpetuate what is in the article. (I also recall another study that found startup founders from broken homes were more successful? yikes? I'm also calling B.S. Freudian analysis here.)

I'm probably more happy when I'm creative and am around creative people. I'm sad when I can't be creative and don't have those outlets.

If you are having trouble with things, there are ways to get a bit better. Talk to someone, look into mindfulness about accepting current things more and worrying less about the future (this is pretty great really), etc. And in some cases you can take actions to make sure you're in a better situation.

I get a lot of good ideas from being around other people. Yes, you do need time to implement them, but having a good feedback loop if you are externally motivated is also a useful thing.

I think it's ok to want to fix the "being unhappy" part, and you can also be creative along the way. We definitely don't want to perpetuate the idea that we have to stay unhappy to be productive. Though this isn't always easy and a lot of people are dealt really hard hands.

There are some good examples of some incredibly unhappy people that were absolute geniuses (Van Gogh!) and also a lot of people that great creative geniuses that aren't as tortured. These things are orthogonal. But there are signs there's a lot of good things going on even when there are a lot of bad things also going on.

Not to say you can't find some good things about being sad about something. Developing empathy and caring about things is a pretty powerful asset. This can cause people to want to do more positive things for the world, knowing what it can feel like for them.

One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates any kind of business logic - or anything that will need to be iterated on by more than one developer. I feel it is a massive reach to market this to anyone at this point, and if this catches on, would really make me hate programming compared to what local development in VMs feels like - where I have much greater tools. It's inefficient both for the developer and at runtime.

Hmm, I have yet to explore any of the skills, but need to.

I tell it to control my Hue lights, and ask it jokes, and occasionally ask it for the weather - though Dark Sky is a lot better for weather data.

So it's not used a ton really.

I'm pretty happy with just

:set nu

:20 # go to line 20

Good post. Random thoughts from me on reducing layoff potential:

When hiring people, hire people that can work in many different roles/projects, think about hiring a person that will improve the business, not just someone to do a particular thing. This is not saying hire marketing/programmer/designers, but rather, know that a software developer can learn anything in a few weeks and is not just a developer in language XYZ.

Hire people when you are really hungry for people and can't handle what you need to do with the number of people you have in a particular area, and you expect that need to be sustained for the long term.

Avoid the idea that you can hire contractors for short term things, when contractors is really a euphism for disposable employees. Push management to hire full time employees.

Make sure there is available revenue and burn rate to cover people. Even if you need help, hiring people when you are in dire straits may be bad for them if finding a new job is difficult. (Still, providing jobs == good).

When projects end, give these folks new jobs and give them time to learn new things, rather than getting rid of them and then hiring new people for the next project that may be booting up in just a few weeks.

Larger companies seem rather guilty of thinking a person just is hired for a department/project, and somehow thinks it's ethical to shut down or shrink whole departments. They should instead look about how to have lots of potential ideas in the pipeline for the future and move people around better.

Again, performance isn't everything.

Go has specialized a bit towards low-level operations, and I tend to strongly dislike what it does with exceptions and the way those involved veto language features.

As for libraries, I'm talking about things on the level of, say, Django or ORMs.

Perhaps a strange choice of the word "synchronized" when coming from Java, this typically implies a critical section. Here it seems to initialize a multiprocessing pool for use in the function labelled concurrent (perhaps)?

In the original article, he indicates Swift, Rust, and Go are tomorrow's languages. The issue really is that the level of support in the various frameworks, the eons of bug-crushing and feature additions, and the libraries available, are going to be behind for some time. This is why I'd still gladly pick Django today.

What is "the future" isn't really so interesting as what is productive.

Yes, performance matters a bit, but development time is usually much more expensive than adding a few nodes to an autoscaling group, and not worth the cost of using less fleshed out libraries.

You are welcome! Thanks!

Yeah it's kind of pixelizing an existing song. What I really want to do is teach a program to jam and know what sounds good - which is a lot harder.

But there's a part of music where human soul needs to be, and that is interesting too, and some of the expression stuff is harder to do in MIDI land, you can modulate a filter cutoff or velocity or something - but compared to a live player there is a LOT of work to do.

Always good to see more computer music projects.

I started on recently - and need to do more work on it - to do some things in a bit more of an object-oriented way trying to model more music theory concepts (like scales) as objects, not so much analyzing existing files but making the primatives you might need to build a sequencer (and eventually some generative stuff).

If people are interested check out:

https://github.com/mpdehaan/camp (in the README, there is mailing list info).

The next thing for me is to make an ASCII sequencer so it's a program that can also be used by people who can't code, and then I'll get back more into the generative parts.

Thanks! Yeah not there anymore but good group of folks! Not too many people pushing immutable systems and continuous deployment so well either, which was nice to see!

NOTE: this is a hoax: https://news.ycombinator.com/item?id=11514455

Not so easily.

I wrote Ansible, but no longer work on it.

There are numerous problems with the hoax.

(A) the user skipped --no-preserve-root to the command, if he really wanted to delete /, he would need to try harder on a modern distro, because the rm command would stop the attempt (B) ansible by default fails on undefined variables, meaning it would never execute the command (C) Jinja template variables are actually {{foo}} not {foo}, so {foo} in bash prints a literal foo

So this triply couldn't happen. Finally, most people should probably be using the file module to delete files, though if people want to call out to the shell they can with any config tool.

I hate this was even posted because it reflects poorly on me and was in exceptionally bad taste to imply ansible would let it happen.

But can you shoot yourself in the foot with any config tool? If you want to, yes. Can you be bitten by a bug? Yes. Do tool authors make mistakes? Yes.

But it was a mean thing to do, and it's not something the tool would even allow, and it hurts when tech journalists (arguably some of the worst reporters in existance) blindly parrot the article without fake checking (just like they'll also do fake comparisons that just recycle blog posts).

Hmm, this is always hard.

The interviewer is trying to recruit you and also filter you out, but usually will not honestly respond to questions about what they don't like, or will hold some of those against you.

Ergo, you really have to ask "what is it like to work here" (and also culture questions, etc) and leave open ended questions, and then learn to read between the lines. Asking multiple people the same question can also be good.

Attempting to gauge enthusiam is good.

I find places that really want to invest in new hires and make them feel part of the team are the best (i.e. people that want to take you out to lunch and help go over code with you), but those are in my experience also a bit too rare.

You also need to figure out if the folks are smart, not burned out too much, and whether there's a lot of politics -- but it's really hard to filter that out from an interview, just in the same way it's hard for people to tell how a candidate is really going to be too.