Tal Bereznitskey

Hire motivated people. Trust them. Set high standards for everything. Lead by example. Get out of their way and let them be the heroes of the day. That’s it.

I’m @ketacode on Twitter.

First, I’d like to say that now is one of the best innovations I’ve seen in deployment since the invention of node and npm. You spin up a working, HTTP/2, secured with TLS app with one command:

now

Then you can link your domain with another:

now alias id mydomain.com

That’s amazing! There’s zero configuration to do, zero forms to fill, zero friction in taking your app to production. I’ll probably be using this a lot, but only for my private and side projects and not for my “real” job.

Why? I’ll detail all the reasons next, but let’s start with the good amazing stuff:

THE AMAZING

They get developers. I mean, they really get developers. They coined a phrase I never heard of before “Developer UX” and this is totally nailing it. You can spin up your pet project (or something larger) without doing anything but writing the word now + pressing Return. You get a new server each time and a new sharable URL.

They get developers 2. Their website is awesome for developers. It has that hacker’s look and reads more like a tutorial than a marketing website. I really enjoy using it, reading the docs and the blog posts.

It’s expanding. Yes, sort of like AWS, it’s becoming an eco-system. Once now was out, domains were being taken care of, secrets and recently they started supporting dockerfiles. So you are no longer limited to node apps. The more things they’ll build, the more value we will get out of it.

Command line first. It’s all from the command line, which is where we spend most of our days. Jumping into a web console is nice, but CLI first makes a lot of sense.

Extendable. It now has node APIs so you can wrap more goodness around it. Check out now-realias for example. It will re-deploy the code and re-link the URL to the new server.

THE WRONG BITS

They don’t get businesses (yet). In the sense that their pricing is less than $15/month which is a joke. I mean, I can’t trust a company charging so little to stay in business long enough. If I can’t trust that, I can’t deploy real production servers to it and sleep well at night.

It’s opaque. While being opaque is one of the sources for that “magic” feeling of “I don’t have to do anything and it just works”, it doesn’t work when you do need answers. It says it is multi-cloud - but doesn’t say which clouds. How is it working behind the scenes? Where is our data stored? Is high availability baked in or not? How is security handled? Where are my servers located in the world? etc… we really need to know to trust it.

Confusing Terminology. Funky new phrases that means little such as “realtime global deployments” and “Dynamic Realtime Scaling” are telling us little about what the service is really is. This makes it sound like an hype - which is what I originally though about now when reading about it. Only after trying it out did I find it is working amazingly well.

A SUGGESTED ROAD PLAN

I wish all the best for now. I wish they will bridge the gap from side projects to businesses (even not enterprise businesses, even for small startups).

My suggested non direct product road plan (they’re doing amazingly well product wise):

1. Create a website targeting businesses. Keep the docs/API section as geeky as it looks now - that works well.
2. Be more transparent about how the architecture is laid out. Build trust by showing how great the operations are.
3. Show uptime and performance benchmarks.
   
4. Collect Success Stories and share them. If I hear of companies working with now - there’s more chance I’ll rely on it.
5. Adjust terminology to “Zero work app deployments”, “Track deployments status in real time”, “Automatic resource scaling” to better capture the core value of their products.
6. Charge more
7. Charge more, as in, way more!
8. Charge a little bit more and it’ll be fine
   

NOW

I really want now to succeed. I believe it can make a lot of change and save a lot of un-needed devops work.

What do you think? Let’s talk on Twitter: @ketacode

Is there really such a thing as a “10x developer”? You can check out the response to this question here: http://10x.engineer/. On the other hand, I believe we can all be 10x more productive than what we do today, or even more than that.

THE SECRET IS SIMPLE

Coding involves a lot of “trial and error” cycles. If we can have 10 times more cycles, we will be a 10x developer. If this is true, we can also be a 22x developers or even a 1,000x developers.

How can we do more cycles in the same amount of time? If you look at a typical coding day, you’ll notice we do a lot of repetitive tasks before we work on our actual task. If we’re building something new, compiling and loading the app takes time. If we’re debugging, reaching to that buggy state is wasted effort. If we’re working on a slow-to-start server than every cycle takes more time than it should.

What if we could skip these repetitive tasks and jump straight into the real work?

I believe that these “10x developers” are people who know how to “hack” things so they only work on their real tasks.

Here are some examples of where you can “hack” yourself more cycles:

• Programming the app to load in a specific state leads to faster testing cycles than loading the app and doing the actions needed to get to that state.
  
• Unit tests can be used for rapid programming. Instead of launching an app/server when you need to check if your code is doing what it’s suppose to. They run in a breeze and you can test your code 22x times more in the same amount of time. You also get testing of that features for life.
• When working on a client side app, use mock data instead of communicating with the server for zero networking.
• Use new tools for hot-loading and replacing code so you don’t even need to build/compile your application.
• Automate things that take time. Add shell aliases for tasks that involve multiple steps. 

Less is more. The more we can reduce, the more cycles we can have. Any more ideas for hacking our way into being a 100X developers? Catch me on @ketacode

TL;DR - Upgrade the careers of your QA engineers to Test Automation engineers (or better yet, become one). Happiness, Velocity and Quality will head your way.

Two years ago, I fired all my QA engineers and re-hired them on the spot to be Test Automation engineers. This was an amazing change for them, being hired for a much more interesting and important position. Also, this set their career path for success.

Their careers were upgraded, but that wasn’t the reason we decided to go for it. I never liked the R&D <–> QA workflow at any company I worked with. Here’s how a typical flow would go:

[START] [—-R&D—-][—-QA—-][–R&D–][–QA–][-R&D-][-QA-] [FINISH]

The developers would write the entire code, almost without testing itself and “throwing it over” to the QA for testing. The Q&A would be blocked on a small bug and couldn’t really test the feature, so it went back to R&D. Rinse and repeat.

WHY I DON’T LIKE THIS PROCESS?

1. No ownership. Developers without QA write better code. Why? Because there’s no one to blame for their mistakes. This is the thing I was most passionate about.
   
2. There are still bugs. Manual testing never finds all the bugs. There might be less, but then we’re limited by the talent of the human testing our product.
3. Ping Pong process. Instead of finishing a feature and shipping it, you have to keep working on it long after you’ve finished. You might already be working on the next feature when the previous feature keeps coming back.
4. Unhappiness. Hate between R&D and QA teams is a regular thing. I know everyone says it’s not, but it is. I always wanted to create harmony while creating our product.
   
5. Repeating the same work. Every single change you make in a codebase, requires the QA team to manually re-test EVERYTHING in the product. Because software…
   
6. One time value. When you test something today, tomorrow that test is worthless. This process doesn’t add value to the company over time.
7. Second class employees. Nobody listens to the QA engineers and it is usually a position you transition from very fast. I want all my employees to be amazing, respected and valuable to their team mates.
8. Human errors. People make mistakes. They miss things, they have mood changes that affects their testing quality.
   
9. Life wasting. I really feel manual QA engineers are wasting their lives clicking buttons. Let’s change that. They’ll still be clicking keyboard buttons, but creating long lasting value with every click.

AUTOMATIC (QA) FOR THE PEOPLE

What is the answer then? That’s a good question. We’ve moved to automatic testing which consists of the following:

• Unit testing - Test that your code does what you think it does.
  Example: expect(add(2, 2)).toEqual(4)
  
• API Testing - Fire API calls to your endpoint, make sure they respond well.
  Example: expect(get(’/item/5’)).toEqual({item: ‘fork’})
• UI Testing - Act as a user who opens a browser/app and starts clicking away.
  Example: open(’google.com’).search(’google’).expect(’not to break internet’)

Each one of this is a world of its own. Unit testing is great for everyone writing code. Some people never run the code they write, a unit test will at least let you do it easily. The assertions are a bonus. If something breaks here, you know exactly what’s not working.

API testing is pretty simple, but you have to setup and teardown tests to bring them back to their initial state. Still, it’s inputs vs outputs which is easy to test. If something breaks here, you know where to look for it in the code.

UI Testing is the hardest. You are dependent that all systems are working during your tests. If something breaks here, you have NO idea where the problem is in your complex system.

DEVELOPING UI TESTS IS A CHALLENGE

As I found out, writing UI Tests is not an easy job. Most of the QA engineers I’ve met could write them, but they were flaky and un-maintainable.

Our developers wrote the next generation of our UI tests and it was a world of difference. We wanted to use JS for writing the tests, because that’s how the browser works. Using Java just seemed wrong. We used nightwatchjs for that and it worked magically.

Tests are written with best practices, go through code reviews and are running after each commit. If you break something, you get an email. That’s like having the best manual QA working 24/7 in best mood emailing you and protecting you.

As a developer, quality is too important for me and I am not going to “outsource” it to anyone else.

What do you think? Drop me a line on Twitter: @ketacode

em·pow·er

To equip or supply with an ability; enable:

Everyone’s talking about empowering their employees. We all want people to spot problems, come up with solutions and complete tasks without or little guidance. Micro-managing isn’t something that works well in jobs that require creativity and using your brain to solve challenging tasks.

I’m also a fan of equipping my team with more power. To be more specific I’m trying to spread impact power™ across the organization. The idea is simple: If each and every one is empowered with real abilities, they can affect and make an true impact in our company.

THE SIMPLE TECHNIQUE

Give everyone an Admin privilege in all tools

It’s simple, if you want people to take more initiatives, they must have the power (and privileges) to try these out. Without this power, employees can’t make a Proof-Of-Concept before suggesting new initiatives - so you get less. Without this power, initiatives can be blocked by managers. Without this power, employees can get de-moralized because they have no power to affect the organization. Give them this power!

“Wait, but what if they screw everything up?” - Old style manager

Yes, that might happen and We’ll have to then work as a team to make it right again. What happens if they don’t have a chance to fail? Will they ever succeed? Giving this power requires trust. You have to trust your employees and they have to trust each other. That’s it.

Here’s how new dialogs in your office will look like:

“You know what would be cool? If we connected X to Y and send Z to before the daily standup” - Empowered Employee

“Go for it.” - You

They’ll be super motivated and will show you their progress along the way and complete it even on their free non working time.

EXAMPLES

AWS - Anyone can experiment with Amazon’s newest technology, spin up a new ELB, connected to RDS, sending messages to SQS [you get the picture]. Giving admin power allowed our team members to find unused machines and save money for the company. It allowed the team to play around with different machine sizes then choose the best one. I wonder what would happen if only one person held the keys to the kingdom.

JIRA - If you’re into configurations, you’d love JIRA. Fortunately, some of our team members love to play with the JIRA configs. Whenever someone has an idea to create a better process, he can just go and add it. If we all agree the new process doesn’t work, we’ll just revert it.

Jenkins - Anyone can make our build process better. One example was adding the ability to deploy from Jenkins. Another example was adding extra information to each build that saves us loads of time each day.

GitHub - Anyone can browse and change the entire code. I never seen a server developer edit our LESS files, but I did get an Android developer reporting errors in an iPhone project.

Slack - Anyone can add integrations. That’s why we can open our front door at the office using a /door command from Slack. It takes one motivated and empowered employee to dream of it and create it.

Tumblr - Have a blog post idea for our tech talk? Go ahead and write it. We usually “code review” it and give feedback. We had people tweaking the themes to allow for gists and that made the blog a bit more awesome than it was.