Over the years, my company’s main application has been under continuous development, evolving and gaining many features. Naturally, as time went by, our engineering team developed many frameworks and utilities that were needed for the app. For example — performance tracking, background worker system, analytics, storage access and even our own ORM, and much more.
Over time, systems as a whole become more robust, and as do their frameworks.
At this point we started to think differently. We can no longer write frameworks that are bound to a certain application. In order to really scale things out, we need to build reusable modules and libraries, which will provide the building blocks for all our applications.
Recently one of our team leaders presented me with the following question:
"What can I do to challenge my developers from a technical point of view, outside of the day to day features scope".
We've all been there before, the routine takes over our day. A feature is followed up by another feature and another feature, leaving us out of breath, and worse - it can worn us out.
As a team leader, you can find additional challenges for your developers, helping them to keep sharp and fresh.
I would like to share with you a couple of ideas we came up with in and you are welcome to add more of your own.
We all want to be better in what we do.
We want our team to move fast and stay focused on our goals. We want to increase velocity and reduce waste.
This process is called optimization, and I have simple guidelines that help me focus on what can really boost my team’s performance.
I call it the Optimization Manifesto, and I wish to share it with you.
Ever since I took my first course in Artificial Intelligence, I have been fascinated by the idea of AI in its classical meaning – teaching machines to perform tasks deemed by us humans as requiring intelligence.
Recently, I gave a talk at my company on some of the intriguing instances of one of these tasks – learning to play (and win!) games. I often found the human stories behind the scenes even more fascinating than the algorithms themselves, and that was my focus in this talk. It was really fun both to assemble as well as deliver, so I wanted to capture these stories in this blog post
Interviewing is hard, it’s a hard and stressful moment for the candidate. But it’s also a very exhausting moment for the interview.
Essentially you have 90 minutes to decide if candidate is competent, matches the company culture, and great person to work with.
In the following posts I’m going to share some of the experience I’ve gathered from interviewing couple of hundreds of people for various technical positions.
I like to use vacation time to reflect on my routine. There is no better time to make sure that my routine is generally happy and as fulfilling as it can be. The vacation itself is a great time to reflect from a position that grants a better perspective on your day-to-day life. But the most critical time when I love to use this tool is on the very last day of the vacation, on the trip back home. At that point in time, your “internal routine thermometer” is at its most accurate. Of course, we all hate it when the vacation is over. But the key question I like to ask myself is, “How do I feel about my routine? How do I feel about returning to it?”. You can’t fake it at this point. If you’re routine sucks and you’re just about to return to it after a brief getaway, you’ll feel it and be very unhappy about your unfortunate future. You feel it in your stomach. I know, because I had times when I felt that way, and with time I knew that something had to change.
As a tester in an agile environment, exploratory testing is a quite familiar testing approach. When exploring, you execute as soon as you think of a test. This is one of the key attributes that distinguishes exploratory testing from scripted testing. As you explore, you discover how the software operates, you learn about its quirks and peculiarities. You watch carefully, looking for subtle clues about where there might be a nest of bugs lurking.
Focusing on the most important information to discover, is one of the core skills of a master explorer. It can be quite tricky and difficult. You will need to find the right balance in your exploratory testing between testing “too deep” or “too shallow”.
A few years ago, I worked for a small startup. It meant the world to me as it had, in one place, so many great things: a bunch of amazing people who became very close friends of mine; a “small gym”; a kitchen that had a variety I could only dream of in my own house; and a laundry service, to name a few.
It felt like my second home and we called ourselves “family”.
I spent 12-hour days there and it felt great! It was as if all my emotional needs were met — I had people who really cared about me, I was meaningful to them, and I made an impact. Together, it gave me a sense of belonging, which allowed me to laugh, cry, and grow up … you get the picture. Sounds familiar, I’m sure.
When you are working on an embedded device, you usually start simple. A main loop that does something.
As you start to add more features, the complexity of the code grows. You add more ifs, more loops, more conditions, and even, god forbid, switch statements.
This is the point when you should to pause and ask yourself: "Am I doing the right thing?"
There must be a better way...
Better way to make these kind of systems, which is not tangled, hard to debug and hardly testable.
Here is a list of things I have learned from *countless* hours playing Strategy Games for more than 35 years (e.g. Chess, Go, Risk, Archon, Warcraft, Red Alert, AoE, Age of Mythology, StarCraft etc.). It is not only cheats.
ESLint is a fantastic linting tool to help enforce your team's code-conventions. I recently introduced ESLint into a codebase to enforce the convention of allowing a script to use dependencies only by explicitly importing them using the module syntax1. Using the built-in ESLint rule Disallow Undeclared Variables (no-undef), it was easy to find (and remove) most dependencies that were declared using the outdated Namespaces convention.
However, I also found some cases where the implicit dependencies exist as properties of other objects, and because of this the no-undef (which only handles variables) doesn't detect them. Thankfully, ESLint can still be used to solve these cases as well.
With so many approaches to management, and of software development in particular, there are plenty of authors who write about it. I don’t intend to join that fray, I enjoy the ‘what’ much more than the ‘how’, but recently this piece of insight dawned on me
I wanted to share with you 6 nice features of Chrome Debugger that can help you improve your site’s performance significantly!
I was reading this great post talking about UX vs UI when an interesting thought caught my mind. The post discusses the differences between UX designer and UI designer, and it occurred to me I've been reading a lot of similar ones lately, covering the software world spectrum.
Many of us in the software industry are discussing the differences between Ops and DevOps, Product and Designers etc.
Discussing the divergence between job titles, talking about what the "other" guys should do, and how they are not doing what they are supposed to do - trying to draw the line on each other's responsibilities.
As part of our work, we strive to establish a performance testing culture across the company.
We wanted to provide fast feedback for the developers in performance aspect the same way as we did with functional tests. That means that we wanted to run performance tests for each commit.
While establishing this culture, we’ve encountered some challenges, which made us question whether we should integrate performance testing as part of the development cycle or not.
If you visit the Google homepage on your desktop, you’ll see a rare, prehistoric specimen – one that most Google users don’t see the point of: the “I’m Feeling Lucky” button.
Google has already removed it from most of its interfaces, and even here it only serves as a teaser for various Google nitwit projects. And yet the way things are going, the “Feeling Lucky” ghost may just come back to life – and with a vengeance.
Inspired by the great book by Ben Horowitz, The Hard Thing About Hard Things, and specifically by this post about good product manager/bad product manager, I felt the urge to re-write it — but this time about engineering managers. From my experience of leading, mentoring and growing dozens of engineering managers I believe there is a huge difference between good engineering managers and bad engineering managers. It might seem very small for some, but in reality only the former can actually build 10x engineering teams.
Previously I’ve talked about the importance of a dedicated time for personal reflection, a retrospective of your life. This tool helps me to improve in all aspects of my life. However, my job is a huge part of my life – and I want to make sure that I also constantly improve in it. Moreover, I want to make sure that I constantly improve it.
Therefore I’ve create a method that allows me to retrospect my work in all its aspects and, most importantly – to share it with my manager. I call it “Weekly Thoughts”.
Most performance issues I've encountered in the past were not because we’ve reached the limits of our tools or our architecture. They were usually because of a more mundane origin: people forgetting indexes, ignoring caches, not bulking queries, writing chatty APIs, fetching way more than needed. Or, if you wish, The real reason behind most performance issues is that people write stupid code.
“A failure” can be a result of a software or hardware problem. A fault tolerance design intents to enable the system to continue operate properly in an event of failure. In this post I’ll talk about a way to treat a special cause of failure – a timeout using a really cool open source framework named Polly.
Previously, we’ve discussed the vision of Continuous Deployment. When people start implementing Continuous Deployment, I’ve noticed that they confuse it with Continuous Delivery.
I’ll try to redefine these from another point of view – the product’s point of view.
In order to cultivate a culture of growth, be able to maintain the velocity while bringing in more talent quickly. You need to have a good balance between new employees’ confidence and their outcome/value. You need to find ways to push them out of their comfort zone as soon as possible. Others might call it “throwing them in at the deep end” - there is a thin line between the two. (http://mettahu.wordpress.com/2013/12/11/leaving-your-comfort-zone/).
The most pragmatic approach for all of the above is to strive to deliver a feature (value) in your first week (or two). This specific action actually triggers real discussions about the company flows, values and ways to improve it.
Seven leadership superpower traits I value most in leaders
Passionate; Inconceivable Tenacity; Hyper Strategist; Inspiring; Craftsmanship; Authentic; Scale Masters
It’s been almost a year. 11 months to be exact. 11 months ago I started to write and described how important it is to take the plunge and just do it in my first post. When I started to write I had very good reasoning. I knew it is a process that is first of all part of my personal growth. So what happened? how could I let almost a year pass before I write another post? Well as always — life happened.
Continuous Integration means a lot to me. It's like my second child. I found out the hard way that this sort of cultural thing is very hard to rely on and maintain inside an ever growing company.
My latest crusade was about ignored tests. When I first came aboard the company, we had many. Since I considered them a broken window, I started handling them one by one.
A while ago I found that interaction with a component in our site results in many detached dom elements. At first glance, it wasn't clear from the code what was causing it.
After some research I realized that the detached dom elements are still referenced by prevObject- an internal property of all jQuery objects which is used by the jQuery .addBack() and .end() methods.
If you're not familiar with prevObject or these two rarely used methods, you can use jQuery chaining in a way that essentially creates a memory leak.
In my particular case the effect on the page's memory consumption was minuscule, and I'm generally against micro-optimizations. But since jQuery is used by many people, and since I couldn't find much info about this topic online, I thought I'd share.
MVC is one of the most commonly used design patterns in web applications. It can be used both with server and client side rendering. Frameworks like ASP.NET MVC and Angular adopted the pattern and made the development extremely easy and straight-forward.
Despite its popularity, I claim that the MVC pattern is no longer the best solution for creating rich and modern web applications.
In the last few months, we experimented with a new company tradition called Leadership Book Club. Before the first session, I had my own prejudices, (e.g.,It’s going to be boring; only strange people will come to such an event; we are going to have an empty room; I don’t want others to choose books for me, etc.). To my delight, reality proved me wrong. The book club session turned out completely differently to the suburban or high school stereotypes. It ended up being a great social activity, and I enjoyed sharing ideas and impressions with friends.
A couple of months ago, I needed to use a laptop of one of my co-workers. When I opened the computer I was baffled by the behavior of the mouse pad. Apparently the mouse direction were inverted – when you go up, the cursor moved down. When you go left the cursor moved right. When I asked him what happened he said there is a malfunction in the pad and he doesn't have time to fix, so instead of fixing it he just got used to it…
Wake Up. Get Dressed. Prepare the kids for School. Send the kids for school.
Drive to the office. Get stuck in Traffic. Work. Drive back home.
Get stuck in traffic (again). Arrive home. Spend some time with the family.
Prepare the kids to sleep. Send the kids to sleep. Send the kids to sleep, again. Take a shower. Spend some time with my wife.
Watch TV/Read a book/Play Games/Workout/Work some more. Go to sleep. Wake Up….
Well, I think you got the picture…
This is my average day with minor tweaks (well I’m lazy so I don’t really workout…) and it more or less worked out pretty well for me.
Well, that is at least until I started to lead my own team.
Leadership; Ship Amazing Products!; Customers 1st; Storytelling; Passionate;
A lot of different factors can affect a web page's performance. For this reason, truly effective Web Performance Optimization starts with identifying the most significant perf bottlenecks of your site. This is usually done with tools likeDevTools, WebPagetest, PageSpeed Insights, etc.
Once you've identified a possible lead, and taken the time to refactor and optimize it, it's important to follow-up by properly validating and understanding the impact of your change. Getting this right will help you learn whether that's something you should race to implement across your site, or a best-practice that in your particular case amounts to a micro-optimization.
This type of analysis is not trivial because web performance data is typically noisy. You can reduce noise by running your optimizations as A/B experiments side-by-side with the existing implementation, and by visualizing your data with a suitable graph such has a histogram.
This post explores these techniques in-depth.