If you’re a Software Engineer getting bombarded with “just a quick question” and “need a small fix”, this post is for you.
It’s your responsibility to handle incoming requests from humans, to say “no” or at least “later” when appropriate. Humans learn, they just need feedback.
If you know such people who get multiple interruptions every hour or you are one of them, please use the email template below and send it to others in your organization. They will respect it, and hopefully with enough cat gifs/emoji included, they might even laugh a bit.
I believe that many team leaders feel constantly under fire because nobody tells them the entire story. They are too busy loading the ship with goods and pushing it forward, without thinking about their crew, their ship, or for that manner, the big blue ocean and the dangers in sailing to the unknown.
Let me start with what your boss does tell you:
So you’re leaving your one-on-one meetings with your boss “checking” every one of the bullets above, yet, you feel as if you’re missing something. …
I remember enjoying Jeff Atwood’s post about “Code isn’t beautiful”. It took me a while explaining to myself why people are chasing after “beautiful code” so much. Why people are so passionate finding or forming beautiful code? Should great painters talk about beautiful colors or beautiful paintbrushes? I always thought they appreciate the entire painting, created and driven from emotions, dreams, ideas, styles and yes — colors & paintbrushes.
Why are we trying to figure out the best paintbrush to use or the best color? …
What if I would tell you that you are outsourcing one of the most powerful motivators at work, without even paying attention?
Do you remember the last time you got a gift at work for your birthday? Well, did one of your teammates actually make the effort of buying and picking it up or was it a “recommendation” passed to Human Resource department, who made it happen?
Looking back at the companies I’ve worked for, it seems that we somehow outsourced most of our ways to show our teammates we care about them. It was comfortable, so naturally, as the company grew, it became easier to outsource the “tedious work” of showing genuine interest and making the effort. …
For some, the term “Proactive Leadership” means being aware of gaps, obstacles and faults before it becomes noticeable to others. The problem though, is that noticing a problem and even taking care of it, doesn’t mean you’re being perceived as proactive leader.
Let me explain — do you remember the last time your boss jumped by and said something like “you noticed that our [feature name] is stuck?” or “I saw that [person] left the office pretty angry, are you doing something about it?”.
“OF COURSE I DID!” you reply, thinking to yourself “thanks for stating the obvious”, saying how you handled the situation just a few hours ago. …
Phone interviews are a wasted opportunity for building a strong engineering brand for your company. I’d like to show you how you can change that with a simple recipe I’ve been using for years with a lot of success.
Every time we are interviewing a candidate over the phone, we invest significant time selling our team and company. We pull out our best story as we want them to get excited about joining us. We usually start by selling the company’s mission: “We’re changing the way [some-awesome-mission-statement-goes-here], by using [ridiculously-unique-technology]”. Then comes the PR quotes we got from TechCrunch, who invested in the company and why we’re going to be a $1B business. …
A few years ago, Brian Chesky of AirBnB shared an email he wrote back in 2013 to his team called Don’t fuck up the Culture. At that point, AirBnB raised more than $120MM in funding.
I though this was an interesting statement. It wasn’t “Don’t fuck up our service availability” or “Don’t fuck up the revenues”.
One of the things I appreciate most in my profession as a Software Engineer is being able to break complexity into smaller, almost tangible parts. …
“A company’s ability to produce laughter on the internet is proportional to its ability to innovate“ — Albert Einstein.
I have to admit that when it comes to comical videos startups produce, I’m always on the hunt. Part of it is trying to make sure I’ll have enough materials for my weekly SoftwareLeadWeekly.com email, and part because I envy their creativity using this medium effectively.
I work at Forter, where we invest every bit of energy and brain power we have into catching fraudsters online. Well, this is not entirely true. We also care about creating a brand that will attract great people to join us, so we could scale not only our product but also our team.
Building a world-class team is not something you’d like to leave to inertia, e.g. “Well, we will just build an awesome product and provide a killer experience to our customers, and great candidates will simply come & knock on our doors”. Good luck with that.
A few months ago, we created SoftwareArchitectureAddict.com (video in Hebrew) to have a good laugh at ourselves, software engineers who “occasionally” find themselves doing just a tiny bit more than required. This video is still shared between engineers in Israel, and it’s quite often when I interview software engineers now, they excitedly ask to meet Itai Frenkel — the main character in the video, and the genius behind the whole thing.
This was fun. It still is. …
The Study: Ariely gave origami novices some paper and instructions to build a (pretty ugly) form. Those who did the origami project, as well as bystanders, were asked in the end how much they’d pay for the product. In a second trial, Ariely hid the instructions from some participants, resulting in a harder process — and an uglier product.
The Results: in the first experiment, the builders paid five times as much as those who just evaluated the product. In the second experiment, the lack of instructions exaggerated this difference: builders valued the ugly-but-difficult products even more highly than the easier, prettier ones, while observers valued them even less. …
I’m a not a big believer in the 10x Engineer myth. I do think, however, that there are things you can do to deliberately improve your software craftsmanship. So the 10x engineer is more about improving your own capacity and skill by a factor of 10, rather than joining an elite group of “10x Engineers”, sitting somewhere in a mythical dark room writing over 200 wpm on their Vim.
It’s not sufficient to practice for the sake of progress. In order to truly grow, you have to deliberately think about your areas of improvement. This is where I believe many people fail to increase their capacity, as picking up new skills or improving existing ones beyond intermediate level is not something that can be built upon inertia.
I was asked recently what I believe is the most challenging part of growing as a software engineer. …