Have you ever wondered what your manager is doing all day? Are you guilty of secretly thinking he/she is playing Candy Crash and attending endless stream of useless meetings? If yes, then you are normal. Management is often invisible and hard to understand. We have tons of books and courses on management but too few good leaders. Sadly, many of us had a bad boss and too of us had a great boss. This post will share my approach to being a good leader.
My management philosophy revolves around three things but one of them is the most important because if we get it right, then all other parts will fall into place. One thing that I care about the most, and which is my main job, is people. I coach, mentor and help people to grow in their careers. I find their strengths and talents. Most people are not that great at self awareness and self observation because their insecurities, desires or emotions interfere with the clear perception of reality. Observing people from outside as a manager or peer gives much better results—a much cleaner and fuller picture.
A few years ago, I managed a team at DocuSign that was tasked with re-writing the main DocuSign web app which was used by tens of millions of users. The APIs didn’t exist yet to support our new shiny front-end app because since the beginning the web app was a .NET monolith. The API team in Seattle was taking the monolith apart and exposing RESTful APIs slowly. This API team consisted of just two engineers and had a release cycle of one month. Our front-end team in San Francisco released every week. The API team release cycle was so long because a lot of (almost all) the functionality had to be tested manually. That’s understandable. It was a monolith without proper automated test coverage after all—when they modified one part, they never knew what can go wrong in other parts of the application.
The Practical Node.js, 2nd Edition print book is finally ready. It turned out the biggest thickest book I ever wrote (500+ pages). Practical Node, 2nd Ed. is even thicker than React Quickly.
My publisher Apress did a great job with design. They printed in color which means readers can see colored code, colored pictures and colored everything. This is never heard of in tech publishing (in my humble opinion).
Practical Node is the same book that was the top seller on Amazon when you search for “node.js” for many many months. Now this book is updated and better with THREE more new chapters and all code in ES6+.
As you know, about a year ago I decided to join Indeed, the world’s #1 job search website. The company mission is simple yet powerful. It’s not a gimmick like in other companies (“Don’t be evil”, really Google?). Indeed’s mission is to help people find jobs. In this fast-changing economy, this mission is paramount.
I am having a great time here at Indeed. In addition to a great mission, there are a lot of interesting projects and smart passionate people. Every day I keep learning new things. You may wonder what I do.
To be more specific about my work, I’m managing several teams in Front-End Core, part of Engineering Capabilities. The teams work on things related to Node and Front-End Developer Experience. We build the back-end and front-end infrastructure for other products and teams. Our work is important because 100s of other software engineers use our services and tools. We are at the leading edge in terms of bringing the best tools and developer experiences.
I’m hiring a full-stack software engineer with the focus on Node into my team in San Francisco. The Indeed’s SF office is convenient. It’s right off Embarcadero and across the new Salesforce Transit Center. We have a huge patio for working, chatting and getting some vitamin D. You can take a look at the office in this video: https://www.youtube.com/watch?v=16Ol-s0xNPg. This engineer will be working next to me, other SF teams and with Node team members in Austin, Seattle and Tokyo. Needless to say, there are exciting travel opportunities and flexible WFH schedule.
A discussion came up in at my work about distinction between a triage and planning meetings. My take on this is that triage reactive whereas planning is active.
Let me illustrate this with examples. Imagine a customer-facing app like a WordPress CMS. Users use the CMS, encounter bugs, and curse. They sometimes report the bugs. An engineering team or a product manager will triage the incoming bugs and issues to sort out what need an urgent fix and what can be deferred. Bugs tend to be urgent but not always important (at least not important for the majority of users).
On the other hand, there is an important task. The CMS has a roadmap to add a paid feature that should increase company revenue and make the next year profitable. The paid feature needs to be implemented. It’s the top priority. Its implementation must be planned actively, separately and before any bugs. If not planned, bugs can take up all the time.
Thus, my suggestion is to plan and plan the priority first. Then plan the triaged work on bugs and tech debt. Focus on important first, not urgent.
I got an email from a person frustrated that he can’t get an entry-level job in IT/tech. He knows PHP, HTML, CSS and MySQL, but he is tired of all the companies rejecting him and requiring a “perfect” expert (as he put it). That’s true that there are not that many entry-level jobs in tech. It’s hard break into tech. Most companies only interview senior engineers with at least five (5) years of industry experience.
As I was editing my new book Practical Node.js, 2nd Edition, I found a few recurring mistakes that my publisher’s editor was correcting. I wrote over dozen of books but I still don’t know some of English grammar. Do you know some of these tricky rules?
Front-end app vs. frontend
Which vs. that
While vs. whereas
May vs. might
Login vs log in
Front-end is an adjective while frontend is a noun. For example, “I build front-end systems”, but “I work on the frontend”.
While and whereas are similar when you contrast two things, but whereas is a bit more formal (and less used in spoken language). While can be used for timing but whereas cannot. For example, “window is a global variable in browsers while/whereas global is in Node”, but “When it’s noisy in cafes, I write code while listening to Spotify”.
May has more probability than might. For example, “I may go to Japan next quarter”, but “I might quit Node.js and move to Denmark to study Artificial Intelligence”.
Finally, login is a noun and log in is a verb. For example, “Implement login using OAuth 2.0”, but “You need to log in to AWS console as admin first and only then create a new user”.
There are multiple ways how software engineers can achieve a successful career. Some can be early employees at Google while others can be a life-long employees of IBM. Some can build side projects while other can get equity. But there are only five common habits and traits:
LEARN: Find balance between learning and doing. Have a solid knowledge of fundamentals either from college degrees or from educating yourself with books and online courses. Constantly apply your knowledge to practice.
WORK: Find balance between productivity and rest. Consistency in productivity is better than burnout.
CONTRIBUTE: Learn the business side of things. Produce highly valuable products which are useful for customers and beneficial for the business.
INNOVATE: Invest in a forward-thinking technology that a reasonable person would expect to become more in demand and desirable over tie.
THINK LONG-TERM: Treat others with respect, honestly and fairly. Think and act long-term. Contribute to open source or teach because it helps you and others.
Hello everyone! In this post, I want to contrast the terms with which other people and we ourselves call us. There are a lot of confusion around the names for our trade. People use terms such as software engineer, software developer. Some people even use programmer or coder, etc., etc. And some event go as far as ninja, guru, or rock star. So let’s take a look at the differences. Of course, it’s all just my opinion but I’ve been in this industry for 15 years. I know a bit or two. So let’s go ahead.
Let’s start from the smallest to the biggest five reasons why programming and software development is awesome.
The reason number 5 (smallest) is programming can pay really well. The average income in the USA is somewhere along $50K per year per household. Programmers typically starts their careers with $80K/year salaries. In major metro areas the salaries are way higher than that. They can easily be in the $120–150K/year range.
The reason number 4 is that you are never bored. There’s always something new. Sometimes new technologies come out before you even release your product. Thus, you are never out of things to learn and update. A lot of people are bored out of their minds at their jobs. Most of them perform the same mundane tasks for 5, 10, 15 years… Not you. Lucky you! Programmers can always grow, learn and master the skills by learning and seeking more challenging problems and solving them.
The reason number 3 is that it’s a real career. Some jobs are not careers. Avoid them. For example, a taxi or an Uber/Lyft driver will always be a driver. A Denny’s waitress will always be a waitress even after 40 years at her job. It’s a dead end. Avoid it. A lot of programmers start as junior developers/engineers, then they progress to associate developers. This could happen in as short as two (2) years. After that, some of them are promoted to senior developers in as short as 3–4 years. That’s not all. The path continues to principal, staff engineer, architect, manager, director, vice president of engineering and to CTO. A lot of tech companies have engineers as their senior leaders, e.g., Microsoft, Google, etc.