Serverless: A lesson learned. The hard way.

The actual cost is now $206 and over $1000 forecasted, it makes me think twice about using pay-per-use services in the future. One little mistake can cost a lot of money, the budget notifications were very late so there was very little I could do against it.

Right now I’m continuously refreshing the billing page on Amazon, hoping it wont go any higher – I probably wont be sleeping much tonight.

I’m not saying serverless is bad, but you should be very careful with it. Keep an eye on your logs, test everything again and again. Set up a budget alarm, even though I still ended up with $206 costs, it could have been much much worse without one.

 

.. This is probably the most stupid thing I ever did. One missing return; ended up costing me $206.

This Is Why Your Best Developers Keep Quitting

YOU WAITED UNTIL THE EXIT INTERVIEW TO ASK WHAT’S WRONG

The fun of solving problems and the joy of seeing something they’ve built come to life is what drives many software developers. Companies need to leave room for the best of them to keep conceiving of–and then executing–new ideas. “If someone who’s been coming to you with their ideas suddenly stops, it’s a huge sign they’re on the way out the door,”

.. “If you have someone saying, ‘I’m bored’ and you don’t do something about it, expect them to leave for a place where they won’t be bored.”

..  That’s why tech leaders should consider holding “stay interviews” with their most valued developers. When the ideas stop flowing or productivity sinks, it’s usually a sign you need to have this type of proactive sit-down.

.. When talking with team members, she probes for a longing to work on newer technologies and listens for any mentions of friends at other companies working on different projects. Even if these remarks are only made off-handedly, she knows they can be red flags. “Don’t be afraid to ask people questions,” she advises: “Are you happy? What’s making you stay? What would make you leave?”

She adds, “Asking ‘Are you okay?’ isn’t illegal.”

 

.. YOU’RE CONFUSING TEACHING WITH MANAGING

The traditional career path is linear, which often means pushing top talent down a management track, supervising others. Leaders may notice that one of their people enjoys teaching others, and then assume that they’d enjoy managing others.

Mentoring and managing might seem similar, but they’re entirely different skills. Management is really about getting work done through others, which makes it highly people-focused. Mentoring or instructing–especially when it comes to software development–is more about a knowledge-transfer of technical skills.

Be careful not to mistake a technical expert who enjoys teaching for one who enjoys managing. Instead, offer your best senior engineers more than just one kind of leadership opportunity; carve out a separate path for technical experts to advance up the ranks based on how well they help their junior colleagues “skill up”–even if that doesn’t involve managing their work.

..  “the number-one reason technical people quit is because they don’t have the option to advance without going into management.”

Szczepanski would likely agree; in his view, developers often get frustrated having to report to leaders who don’t have tech backgrounds themselves.

The nihilist and optimist programmers

The nihilist programmer takes as axiomatic that their product is already broken. It is in constant flux, poorly defined, the product of compromise in design, and inevitably compromised in implementation. Even more, that it will remain this way, by its nature, forever. The nihilist programmer starts from these axioms and then decides what to do. What to do? The least amount of change possible. Limit exposure, limit effect. Get to the next checkpoint.

The particular medicine isn’t a bad one, per se. There’s value in those limits. What’s bad, I think, is the ethos. If a thing is undefinable, you will naturally resist efforts to define it. If a thing is forever in flux, you will resist efforts to freeze it. If a thing is composed exclusively of compromise, you will resist efforts to make decisive decisions. And if a thing will never be good, you will resist efforts to make it good.

.. The optimist programmer assumes the thing can be good, and constantly initiates to make it good. That the thing shouldn’t contain compromise, and should reflect clear decisions. That the thing should be defined and then built, and not rock forever on a sea of changing assumptions. That the thing ought rightly be defined, that its true form is definitional.

.. Successful projects live somewhere in the middle. But I think all good software is fundamentally optimistic. Not that it won’t contain compromise, or technical debt to be repaid, but that it doesn’t start from the assumption that nothing is definite and all hope is lost. Optimistic software makes decisive claims, executes on them, and owns the compromises it makes.

Elastic tabstops – a better way to indent and align code

Since the days of the character mapped display, programmers have argued over whether tabs or spaces should be used to line up text. While both strategies can be used if all of a project’s programmers can agree on how many spaces wide a tab should be, experience has taught us that this is not always the case. Even if all of the programmers working on a project are diligent enough to stick to only using tabs or spaces and have tabs set to the agreed number of spaces, there is still a problem if any programmers wish to use modern proportional fonts (because a space is no longer the same width as every other character).

The reason why we have not yet settled conclusively on either tabs or spaces is that both camps can point to problems in the others’ approach. The truth is that both are right to be critical