Category Archives: Advices

Join My Node Team at Indeed in SF: Great Impact, Life and Rewards

Join My Node Team at Indeed in SF: Great Impact, Life and Rewards

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.

Continue reading

Triage vs. Planning

Triage vs. Planning

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.

Breaking Into IT and Tech as a Beginner

Breaking Into IT and Tech as a Beginner

Breaking Into IT and Tech as a Beginner

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.

Continue reading

Tricky English Grammar for Programmers

Tricky English Grammar for Programmers

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”.

Which needs comma and it is less important than that, which is used without a comma. The which clause can be removed but the that one cannot be removed without the loss of the meaning. For example, “I like Node.js, which is JavaScript on the server”, but “Create a file that starts the Koa server”.

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”.

5 Habits of Highly Successful Software Engineers

5 Habits of Highly Successful Software Engineers

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:

  1. 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.
  2. WORK: Find balance between productivity and rest. Consistency in productivity is better than burnout.
  3. CONTRIBUTE: Learn the business side of things. Produce highly valuable products which are useful for customers and beneficial for the business.
  4. INNOVATE: Invest in a forward-thinking technology that a reasonable person would expect to become more in demand and desirable over tie.
  5. 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.

Programmer vs. Software Engineer vs. Software Developer vs. Coder

Programmer vs. Software Engineer vs. Developer vs. Coder

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.

Continue reading

5 Reasons Programming is Awesome

5 Reasons Programming is Awesome

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.

Continue reading

My New Book Concept and Top Qualities of a Good Software Engineers

My New Book Concept and Top Qualities of a Good Software Engineers

Packt Publishing reached out to me and offered to do a book.

They pretty much want me to do any book and pre-agreed already. They gave me carte blanche on the topic.

(More or less, I doubt I can convince them to publish a vampire thriller set in a Silicon Valley startup.)

Funny thing is that I know the editor. He worked at Apress Media when I published my first book Practical Node.js with them.

I submitted to them my idea about a software engineering career book for junior developers. They liked it. It can become a book!

While thinking about the career in software engineering, I thought about top skills.

As in any profession, software engineers requires a combination of certain skills and techniques.
I’ve done software engineering for over 15 years.
I taught total beginners (in Hack Reactor) and professionals (in Fortune 500 companies).

The most important skill in a good software engineer is not smarts. No. It’s not how good he can write code.
It’s not soft skills either

Continue reading

Born vs Made Programmers

Born vs Made Programmers

Are programmers born or made? It depends. In 2010s, programming is so much easier than it used to be in 2000s. More and more gurus and dev bootcamp founders proclaim that programmers can be made.

I won’t say programmers are made. My answer: it depends. Instead of thinking programmers are made, utilize whatever belief is more useful to you.

If you are starting on the programming path later in your life as a second (or third, or fourth) career choice, then thinking programmers are born is detrimental! Why would you do such a thing?

Think and truly believe that programmers are made, if you want to succeed as a programmer. That’s because every time you encounter an issue, you’ll be inclined to work through it when you think that NOW you are a programmer.

On the contrary, you will be more successful thinking programmers are born, if you has been programming from your teens and programming is the only career you ever had. The reason is when you encounter a problem, you’ll be forced to find a solution because that’s what you do. You are a programmer and alway was. You have to come up with the answer because you are a programmer. You’ll value your job and think it’s your missing to write great software, because you won a lucky lottery.

If we dig deeper, programmer are not born. No one in the hospital looks at a child and says “congratulations, that’s a programmer”, “you are luckliy, that’s a QA engineer”, “sorry, that’s a designer”. No. Most likely it’s a dumb luck. The kid got a computer as an early age and tried programming and liked it. Then he got more experience and made himself into a programmer. So born is actually made just at an earlier age.

In any case, think and believe whatever is more useful to you in your career and life. Not what someone else tells you.