Have you ever walked into an office and saw a huge flat screen on the wall displaying a dashboard with pretty graphs, or some other nice visualization showing some important looking numbers? Back when people still frequented offices, many had them. But have you ever wondered, what are they for? No engineer is looking at them, because when you are looking at data you want to interact with the data, zoom, pan or apply some filter. And if the data requires immediate action, you would set an alert. So what is the dashboard for?

From meetup groups to job listings to titles on LinkedIn, full-stackers are all around. but for a term so prevalent it is surprisingly ambiguous. What is a “full-stack” developer? What does she do? What is the scope of her work? Does our company need one? Practical questions I imagine have crossed the minds of many VP R&Ds and CTOs. It would have been nice to have a common definition, but human languages is dynamic and evolves, so fragmentation and ambiguity are part of the game. Mostly it works and we can rely on our intuitive understanding of the terms used. However, in some situations it’s worth choosing a more accurate term, or even use a full sentence to describe what you mean because ambiguity might be costly. For example, when writing a resume or a recruitment ad you might want to be explicit about what it is you are looking for. Sadly, this is exactly where we see the ambiguous term “full stack” used the most - I tend to think of resumes and job listings as marketing material so I expect them to be hip and ambiguous, but this does present a problem: how do I know if “full stack” is right for me?

Since I’ve abandoned Facebook my primary source of tech news has become Twitter and this week my feed is raging with two seemingly unrelated security/privacy incidents: Zoom’s zero day and Superhuman’s email tracking scandal. I write “seemingly”, because despite these being two very different companies operating in two different markets (Zoom in video conference calls and Superhuman in emails), building very different products (Zoom is all about jump in, jump out - Superhuman is a workspace) these incidents stem from the same fundamental fault: The telephone experience.

A few months back, the twittershphere rumbled on how wrong it is that conference speakers are not paid. In tweets and blogs, people have called out for conferences to pay speakers travel expenses and even pay them a fee for their work in preparing and delivering the talks. As an example, this article on medium.com.

Initially, I was taken by the arguments: If someone is travelling from afar to speak, their costs should be reimburse. If one is devoting her time to create good talks, she should be paid for her work. Conferences cannot happen without the speakers. The substantial expenses involved with speaking reduce the size of speakers pool.

I’m usually a private person and I don’t publicly write about personal stuff - This is my first ever personal public piece. There are several reasons why I’m writing this; Since John Willis brought up the issue of burnout to the spotlight there has been a spur of blog posts and articles about burnout and some people have been gracious enough to share their personal story. After reading people’s stories I came to realize how important it is to share those experiences, I’ll get back to that in the end. For some people, burnout is the result of work taxing their life too much. For others, personal affairs is what send them over the edge. Every case is different and unique - but the result is usually the same. Today is my turn to share my story.

Every corporation and enterprise want a private cloud these days. The arguments vary from company to company, usually revolving around security, cost, independence and strangely enough — reliability. I could argue that given the track record of most enterprise IT departments it seems dubious they can improve even one of these parameters compared to a public cloud, but I won’t. It turns out there’s no point refuting those arguments, because, and I cannot emphasize this enough:

You are going to end up using a public cloud, even if it’s more expensive and less secure, less reliable and less independent

Reliability promotes failures. Failures promote reliability

When a system is reliable long enough, production pressure causes the operators to drive the system harder; Over time operators become less careful as the trauma of the last failure wears off. More workload is applied, new features introduced, etc, until the system trails again into the danger zone (e.g. high load once thought to be dangerous), sailing through smoothly this time, thus boosting the confidence of operators in the robustness of their system. Eventually the system does fail and after several such failures safety again becomes a higher priority than production - now effort is put into making the system safe again and the cycle begins once more.

A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it. Max Planck, Scientific Autobiography

As I became more involved in workshops and training, I observed many people coming from old-school sysadmin backgrounds struggle with the moderns tools and methodologies that the SRE and DevOps movements are promoting. I often wonder why it so hard for some of them to learn the “new ways”. I’ve heard many people comment (often disrespectfully) that these difficulties are due to lack of “technical skills” - frequently citing poor programming abilities. While I agree this may be a real problem for some people, this explanation is far from being sufficient.

During my years of consulting, I’ve run into many managers (in enterprises and startup companies alike) who just didn’t get this whole “technical debt” thing. You’ve run into those managers too, I’m sure - the kind of manager who issues pressing deadlines, marks bug reports for left-over time (which never comes), relies on VMotion or fancy SAN for high availability, refuses upgrades because of “risks” and urges you to “stop wasting your time listening to tech talks and go write features”. I’ve even heard managers tell engineers “don’t waste your time learning this framework, just write your system with it” (!!!)

I’ve often wondered - why is it so hard for them to get something that is so painfully obvious to the majority of software engineers?

2 - a technical co-founder and a business co-founder. Since they don’t have enough money for proper lightbulb they use an old socket and lightbulb they found in the garage and since they don’t fit the technical co-founder builds a makeshift adapter from duct tape and aluminum foil. This actually works as long as you don’t tilt it too much. During seed negotiations the co-founders break up and the technical co-founder leaves.