Category Archives: Advices

One Technique Guaranteed to Improve Your Coding Skill FREE

One Technique to Guaranteed to Improve Your Coding Skills for FREE

What if I told you, there’s a one technique which will GUARANTEE an improvement in your coding skills and… it’s FREE. There’s no need for a partner, or expensive equipment, or supplements/nootropics. I’ve been using it for many years now and I became much better software engineer as a result. I was able to write 14 technical books while having a full-time job coding, speaking at conferences and teaching workshops all over the world.

More over, a lot of people outside of tech and coding use this technique to gain great advantage and improvement in their work: actors, writers, athletes, etc. It’s one of the best kept secrets and has been for many hundreds of years and probably longer. But hundreds of year ago, only select few people knew about this technique. Now anyone can tap into its power… but will you be the one to rip the benefits of this awesome technique for your career?

But let’s get back to coding.

Let me ask you: What is the most important important skill in coding?

What allows you to dig deeper into a problem and come up with a solution? No. Programming languages and apps are just tools.

To make it more specific, what allows you to track a function call and keep in memory three different variable values while also applying methods on an array and noticing places where you can refactor the code to make it better?

Let me give you the hint: experienced programmers (10+ years) have this skill in abundance. This is why they can solve complex problems and work with technologies which make any one else on their team cry like small baby. Senior programmers are masters of this skill and I won’t be surprised to find out that most of them use this productivity-boosting technique.

Do you know by now?

Can you guess?

It’s focus! Focus is the most important skill for a programmer. If you can focus more, then you can solve very complex problems. If you can change your focus from one thing to another faster, then you can be more productive. Most coding tasks require focus, e.g., finding bugs or find abstraction patterns to improve code and systems.

And what is a free technique to improve the focus? It’s meditation. It’s free. There’s no need for equipment. There’s no need for a partner. It’s affordable to anyone!

Any excuses like “I’m not good at meditation” just means you need meditation the MOST to calm your monkey brain. In our world of Slack, Facebook, Twitter, Snapchat and open offices it’s the people who can perform deep work that will be value and will get ahead.

Not convinced? Meditation is popular in India and look how many programmers from India are out there! I’m not saying I have hard data to prove anything. It could be just a coincidence, but my gut feeling is that there must be something to it.

Also, programming itself is a state of a blissful flow or trance. The more you do it the better you become at going into the flow state. Programming itself is like a meditation!

I paid more than $3,000 for my yoga teacher training. That’s an expensive way to learn meditation which basically what yoga is. Luckily, you don’t have to pay as much unless you want to have a motivation from spending all that money.

You can start just by counting from one to four for FREE. Start with 5 minutes per day for 1 month, then increase to 10 minutes. Give it a few months. Notice any improvement in your ability to focus while coding. Leave a comment here or write me an email about your results.

On Tech Leadership: Managing Humans Summary

Managing Humans
Managing Humans

Managing Humans

Here is the summary for Managing Humans, a book on software engineering management along with my interpretation and comments. Text in quote are direct excerpts from the book.

  • People on your team have different needs, e.g., promotion, challenge, less stress. By filling their needs, you can make them content and productive. Your job as a leader is to listen to them and mentally document how they are wired. This is the essence of a software manager’s job.
  • Manager is connector between the team and the rest of the organization. The main way for an engineer to show the work to the company is to communicate to the manager. Hence should balance external and internal focus.
  • “Schedule one-on-ones with direct reports, keep them on the same day and time, and never cancel them.” One-on-ones are paramount. Keep them regular and at least 30 min. Maybe 45min is better. Not 15min. Avoid missing scheduled one-on-ones and doing status reports. Weekly is the best. These meetings are for managers to listen 50%+. If no issues, then focus on career building and needs of your reports.
  • Know your boss’ place… and yours, in the food chain besides just the title of the org chart. “Politically active managers are informed managers. They know when change is afoot and they know what action to take to best represent their organization.”
  • In a meeting, if someone is doing anything else except listening (open laptop? iPhone?), he is not listening. Ban laptops from your meetings altogether. Paper notebooks still work for notes (info can be digitized later), and they don’t require charging unlike laptops.
  • In conflict resolution, listen to both stories. Preferably in-person not over email. People prone to unconsciously augment memory, misinterpret and twist facts to make a story in their favor. “If the story can’t stand up to the first three questions that pop into your mind, then there’s an issue”
  • Two pizza team rule. With more than 10–15 direct reports it becomes extremely hard to really listen people.
  • Sometimes just listening helps to vent a frustration. If communication is broken, then listen and repeat to understand.
  • Meetings must have an agenda at the beginning, and a clear set of actionable steps at the end.
  • Incrementalist vs. perfectionists. In a deadlock, it’s better to make an “executive” decision to move forward.
  • “In the absence of information, people will create their own”. Kill gossips in your staff meetings. Don’t spread them yourself and prevent others from spreading them. Also, don’t tell too much. “As a manager, your job is that of a bullshit umbrella”.
  • “The point of a performance review is not the review itself but the conversation that stems from it”. Send the report a few days in advance so it’s not a shock to the team member. Aim to mitigate any boredom and complacency by giving directions, i.e., learn Elixir.
  • Speak the same language as the person you’re talking to: managerial (managementese) with other leads and technical with coders.
  • Off-sites help remove day-to-day distractions and focus on strategic.
  • If you want to progress as a manager, you need to stop coding while still coding but on prototypes, research, proof-of-concepts, i.e., no core products. This way you are still in the latest trends but not an impediment if you fail to deliver a critical feature or worse delivered a bug which crashed other parts (and your team had to fix it). “Stay flexible, remember what it means to be an engineer, and don’t stop developing”.
  • Always allow your team to question your decisions but once the decision is made—all hands on board.
  • Process must be a documentation of the engineering culture and value so it can be passed along to new members when engineers leave or company grows. Process must NOT be a way to control.
  • Humans are bad at estimations. It becomes a bit better once they start working on a task.
  • Project manager makes sure to ship the product; product manager makes sure that the right product is shipped; while program manager makes sure multiple (typically interelated and dependent) products are shipped, generally at the same time.
  • Rotate your engineering between boring tasks like bug fixes, tests or tech debt.
  • Each new engineer bring overhead of communication, decision, and error correction. (Read The Mythical Man-Month). Ensure the cultural fit. All things equal, it’s better to hire for attitude than skill. Know about strategic vs. tactical visions.
  • Engineers treasure consistency, predictability, and efficiency.
  • There are mechanical (data oriented) and organic (human oriented) managers. Make sure you speak with them on their level not yours.

Continue reading

Beautiful Node APIs

Beautiful Node APIs

This post is on how to build beautiful APIs in Node.js. Great, and what is an API? The definition says Application Programming Interface, but what does it mean? It could mean on of the few things depending on the context:

  • Endpoints of a service service-oriented architecture (SOA)
  • Function signature
  • Class attribute and methods

The main idea is that an API is a form of a contract between two or more entities (objects, classes, concerns, etc.). Your main goal as a Node engineer is to build beautiful API so that developers who consume your module/class/service won’t be cursing and sending you hate IM and mail. The rest of your code can be ugly but the parts which are public (mean for usage by other programs, and developers) need to be conventional, extendable, simple to use and understand, and consistent.

Let’s see how to build beautiful APIs for which you can make sure other developer

Continue reading

10 Things You Should Stop Doing When Giving a Conference Talk

10 Things You Should Stop Doing When Giving a Conference Talk

I’ve spoken at over a dozen conferences this year and seen my share of bad presentations. Yes, for the most part geeks aren’t expected to be great at public speaking. That’s why they called geeks.

However, I noticed certain patterns: most of the times presenters were making it harder for the audience to get their material. They were doing some easy to fix things which hampered their delivery greatly. The tech talks are boring anyway (generally speaking). Why make it even hard on your listeners?

If you need to present soon at a conference (even if you are not a geek or techie), here are 10 sins you should never do when you give a conference talk (more of a note to myself than anything else):

Continue reading

Software Engineering Future: How Your Job is Becoming a Commodity and Might Even Disappear

Software Engineering Future: How Your Job is Becoming a Commodity and Might Even Disappear

My musings on why it might be the time to start looking for a new profession if you are a software engineer?

You know how in the early 20th century pilots were like heroes? It was extremely dangerous to fly planes which were highly unreliable. Most of the time, only true adventures would learn how to fly a plane and become a pilot.

Then, fast forward 50 years and during 1950s, we started to have first commercial flights. It was still prestigious to become a pilot. If you remember, Catch Me If You Can, the villain played by Leo DiCaprio used pilot’s uniform to instill more trust in other people so he can cash fake checks.

In the 21th century, most airlines don’t make much money and they operate on a slim margin. The pilot’s job has become a commodity: there are a lot of schools and you need to study many years to become a pilot, but you get paid not that much more money than a bus driver. Autopilot is doing most of the flying except for landing and take offs. Airlines constantly merge and layoff their staff. Most of the times the attire is not as sharp as we see on pilots in movies, old newspapers and posters.

I believe almost every profession or trade undergoes a few cycles not dissimilar to the famous adoption curve. There are five steps, but I’ll simplify it to just three:

  • In the beginning, there’s very little reward but a high entry barrier
  • In the middle, you get most benefits from the wider demand for a certain skill and it’s less risky and less troublesome to get started in it
  • In the final phase, you get even smaller barrier to entry the profession: there are a lot of known paths, schools, books, best practices. Then also the tools and equipment becomes better than in the first two phases. However, the demand and the benefits to an individual from that profession diminish compare to what it was in the middle phase.

After the third phase, the profession become a commodity. It’s not necessarily a disaster for people in this trade, but it’s certainly not a rarity. Then, the profession can event disappear completely! I’m sure you can come up with some examples that disprove my little theory, but before you do so, let’s take a look at programming.

Continue reading

One Year with Capital One: Lessons Learned

One Year with Capital One

Today is exactly one year and ten days since I started my work as a Technology Fellow at fintech startup Capital One. Yes, I wrote before while you shouldn’t work in a startup, and I still believe in it, because Capital One is not a startup in a traditional sense. On the contrary, it’s in the top 10 US banks list as of 2016. Let me explain myself.
Continue reading

Dirty Little Secret About QWERTY Layout and How I Switched to Colemak to Reduce Trauma and Gain Productivity

Dirty Little Secret About QWERTY Layout

Typing is everywhere right now. We type for work in emails and on IM clients, we type for personal relationships on Facebook (when was the last time you spoke with a friend on a phone?), and we type to have fun in Whatsapp or iMessages. Then of course, we code in editors and IDEs, and type commands in shells.

Imagine that you woke up tomorrow and weren’t able to use your keyboard. Maybe you would have broken both of your wrists skiing… Terrible, right? Even if you don’t write books or blog posts like I do, typing on a keyboard is how most of us live. And touch screen typing and voice dictation take only small roles. Let me tell you why you might be in danger of losing your ability to type and maybe even close to losing your job, career and relationships.

Continue reading

React for Fun and Profit

React is a fun little library for User Interfaces. You can use it for web, or mobile development. It’s fun because it’s very developer-friendly. You write your code in the same place without having to switch between HTML and JavaScript files.

I’ve heard many times people complaining about React’s favorite syntax JSX. I found it great, after I spent a few hours learning and coding with it. Contrary to what people unfamiliar with React think, JSX is not HTML in JavaScript. JSX is just an XML-like syntax which produces JavaScript. There’s not HTML involved at this step. When you develop with React, you write JavaScript objects. Later React automagically transforms those object into rendered HTML.

Also, React is very fast due to its virtual DOM and smart diffing algorithm. And React’s component approach to architecture allows for great development scalability. Just ask Facebook, Twitter, Slack and other companies with large web apps.

Furthermore, you can use React with React Native to create native iOS and Android apps. These apps can share the same code. It’s not the same as the so called hybrid or HTML5 apps. The latter are websites trapped into a headless browser in a mobile app. The former is a real native app which uses JavaScript interface for it’s UIs and logic.

Hey, you can even use live reloading when developing apps with React Native. Pure joy! The feature native mobile developers can only dream of! “React is fun, but show me the money”— you can yell. Fair enough.

Continue reading