eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Life is made up of moments; some good, some not so good, and everything in between. It’s what we do with all these moments—mainly what we learn from them—that ultimately comprises the decisions and non-decisions of a lifetime.
The cool thing now is that we’re able to record many more of these moments with our ever-present mobile devices, whether video, audio or document, as time goes on. That way we can keep history straight and not invite revisionist stories into the memory bank.
This article is a little unusual for eWEEK, because we tend to stick with stories about enterprise business, the value of new products and ideas, and the uncovering of trends in the tech markets we cover. But there also should be room for occasional human-interest articles in our publication. After all, IT is all about helping humans get things done, be entertained and stay in touch with each other—is it not?
In light of all this, here are some brief glimpses into “a-ha!” type moments for a set of entrepreneurial tech executives, compiled by Amber Rowland.
Charity Majors, Co-Founder and CTO of Honeycomb.io:
“I used to have a bad case of imposter syndrome, like many (most?) of us in tech. I felt like a drag to the team, like I was always banging my head for too long against problems or patiently waiting around for help, trying to be small and inconspicuous and not too much of a bother. I tried to load balance who I went to for help so that I wouldn’t wear anyone out, and I hoped they wouldn’t notice how much help I needed.
“My sense of not being truly qualified was made more acute by the fact that I didn’t have a degree and hadn’t really studied computers; I was a piano major and a dropout who learned everything by myself in the basement computer lab at school. I felt this hanging over my head like a neon sign every time I asked for help.
“I was three years into my first job after dropping out, when I first noticed how many people were also coming to *me* for help. It surprised me! But I had built the system from the ground up, and even senior people were coming to me every day for help understanding it. I started to track this out of curiosity. And one day I realized that people were coming to me for help consistently more than I was going to them for help. I felt a switch flip that day; I don’t think I’ve ever felt bad about asking for help ever since.”
Matthew Fornaciari, CTO and Co-Founder of Gremlin:
“After just a few months into my time at Amazon, my manager called me into his office and dropped a bomb: “Jeff and the leadership team want an automated weekly report of the gnarliest new server errors,” he explained flatly, “And they want it in two weeks.”
“Most of my programming experience until this point had been in the classroom, where projects were meticulously defined, scoped and self-contained. The thought of not only defining, but implementing, a robust solution in this timeframe was daunting. Luckily, I was currently working my way through ‘The Pragmatic Programmer,’ and just so happened to be perusing the section on ‘tracer code.’ For those unfamiliar with the idea, it’s best explained as code that is “lean but complete, and forms part of the skeleton of the final system.”
“The ‘aha moment’ came when I stopped asking myself what corner cases I should be considering and started asking myself what was the least amount of poignant code I could write to solve the crux of the problem. By stripping the problem down to its most important components, I was able to deliver the report on time. Not only that, but I was then able to continue layering in functionality, based on feedback from the leadership team, for years to come. These days my role is significantly different than it was back then, but I’ve never stopped asking: ‘What is the bare bones solution to this problem?’”
Liran Haimovitch, Co-Founder and CTO of Rookout:
“My ‘aha’ moment was when I realized how important it is to be willing to change your process, even if you’ve been doing something a certain way for years. Software evolves at an insatiable speed, yet some beliefs are hardcoded into our minds as developers. Just over two years ago, my co-founder Or Weis and I found ourselves ranting about a long-held frustration: When running code in production, you are constantly trying to figure out what your code is actually doing and why. Even though it’s your code, running on your servers, there’s no easy way to see what’s going on. You have to write more code, test it, approve it, deploy it, and only then do you get a new sliver of data.
“We started to question this process: What if the developer workflow could actually be reversed? Is it possible to get the data without stopping the application? Without writing new code? It percolated for a long time. And we did eventually change the way we approach observability and built a company around a new workflow. But the ‘aha’ moment wasn’t about the technological solution, but rather being willing to keep our workflow flexible and open to new paradigms.”
Anurag Goel, Founder and CEO of Render:
“The most helpful personal change I’ve made as a developer is to build a habit of intentional learning. Early in my career, my growth as an engineer was accidental: I was learning only by doing my day job. This not only made it painfully slow for me to improve, but it also prevented me from picking up crucial engineering skills that weren’t directly related to my work. Growth requires both conscious intent and discipline, and I had to work hard to build a habit of deliberate practice and methodical self education.
“In practical terms, this meant reading programming books instead of just blog posts on ‘Hacker News’; explicitly learning new languages by building large side projects instead of following simple tutorials; and systematically reading code for open source projects that weren’t related to work. I found that these simple steps allowed me to think much more productively about code, in a way that has only compounded over the years.”
Rob Skillington, Co-Founder and CTO of Chronosphere:
“When facing challenges, I typically try to pattern match in order to see if others have conquered the same problems. One thing that stood out to me in Jeff Dean’s widely distributed talk titled ‘Designs, Lessons and Advice from Building Large Distributed Systems,’ was the importance of understanding systems top down; of being able to understand how it performs from the outermost layer to the innermost layer. Jeff asks, ‘If your system is slow or misbehaving, can you figure out why?’
“As anyone who has worked at a startup knows, accomplishing big things with small teams can be hard, especially when you need to continually ship reliable software with growing complexity and/or request volume.
“Early on when we were scaling services at Uber, seeing the results of our theories with reliable, real-time instrumentation and metrics changed how we approached our work. Once we understood the system and the effects our changes had from analyzing the outermost layers to the innermost with metrics, we could ship features reliably and we could measure user engagement / impact along different axes immediately. It also made debugging specific problems faster, since we knew what was happening at a high level and where to look to find the relevant logs and individual request/responses to analyze. This experience made me realize that I could make better data-driven decisions; I just need to look for the signals at each opportunity.”
Saad Malik, Co-Founder and CTO, Spectro Cloud:
“Watching the ‘Silicon Valley’ episode where Richard is arguing with his soon-to-be-ex girlfriend about tabs vs. spaces brings back some nostalgic memories. There was a time not long ago, where I was that engineer preaching with conviction (but arguably questionable rationale) about why everyone should use tabs. As expected, there were others on the team who felt otherwise. What started as an innocuous disagreement developed into something substantial: hidden ‘code preference’ configuration files, specialized diffing tools, and even custom code reformatters. It was a MESS! We realized that we caused ourselves a lot of angst and confusion by simply not deciding as a team whether we should use tabs or spaces (a decision that is relatively inconsequential). In software development as in life, after weighing all of your options, it’s often better to make a reasonable decision and commit, than to make no decision at all.”
If you have a suggestion for an eWEEK Data Points article, email cpreimesberger@eweek.com.