Category: Advices

Top Five Traits of a Good Software Engineer and How to Develop Them

I’ve been in software engineering/development for over 20 years. I’ve noticed when I did a good job and when not. I’ve noticed how others have struggled to do a good job and what inhibited their potential. Here is my list of top five traits and abilities that distinguish a good software engineer.

  1. Focus
    • Deep Work: The ability to engage in deep work, which involves extended periods of uninterrupted concentration, is crucial. This allows for the tackling of complex problems and the development of innovative solutions.
    • Task Prioritization: Effective focus requires the ability to prioritize tasks and manage time effectively, ensuring that the most critical tasks receive the necessary attention.
    • Minimizing Distractions: Developing strategies to minimize distractions, whether they are from the environment, such as noise, or from digital sources, like social media, is essential to maintain high productivity.
  2. Stamina
    • Physical Endurance: The ability to sit and work for long hours without compromising health. This can be enhanced by maintaining good posture, taking regular breaks, and incorporating physical exercise into daily routines.
    • Adaptability to Environments: Being comfortable working in various environments, from noisy open office plans to cramped airplane seats, and still maintaining productivity.
    • Mental Resilience: The mental endurance to push through tough, monotonous tasks and stay motivated during long projects, especially when faced with tight deadlines or challenging problems.
  3. Logical Thinking
    • Analytical Skills: Breaking down complex problems into smaller, manageable components and analyzing each part systematically to find a solution.
    • Debugging Proficiency: Developing a methodical approach to debugging, including understanding error messages, using debugging tools, and writing tests to identify and fix issues.
    • Algorithmic Thinking: Applying logical thinking to design efficient algorithms and optimize existing code, ensuring that solutions are not only correct but also performant.
  4. Good Memory
    • Knowledge Retention: Retaining information about the codebase, including classes, libraries, and methods, to avoid redundant searches and improve coding efficiency.
    • Pattern Recognition: Recognizing patterns in problems and solutions, allowing for the application of previously successful strategies to new challenges.
    • Continual Learning: Keeping up-to-date with new technologies and remembering how they integrate with existing systems to maintain a modern and efficient workflow.
  5. Good Communication and Writing Skills
    • Clear Documentation: Writing clear and concise documentation for code, APIs, and systems that can be easily understood by other developers, both current and future.
    • Effective Communication: Clearly expressing ideas and solutions in written form, whether in emails, reports, or code comments, ensuring that all stakeholders have a clear understanding of the project’s status and requirements.
    • Collaboration: Writing detailed instructions and guides for colleagues, facilitating collaboration, and ensuring that team members can quickly understand and contribute to the project.

Practical Tips for Developing Top Traits for Software Engineer

  1. Focus
    • Practice techniques like Pomodoro for time management.
    • Create a distraction-free work environment by using noise-canceling headphones or software that blocks distracting websites (or even better turn off the internet).
    • Pick a quiet room without windows or any other distractions. Cafes and modern open offices are not for software engineering work.
  2. Stamina
    • Incorporate regular physical activity into your routine and healthy eating to build physical stamina.
    • Use ergonomic furniture to reduce physical strain during long work sessions.
    • Do regular eye exams to reduce fatigue due to poor vision and strain on the brain through eyes.
  3. Logical Thinking
    • Play chess or checkers, solve puzzles and engage in activities that require critical thinking to sharpen your logical skills.
    • Regularly practice coding problems on platforms like LeetCode or HackerRank.
    • Engage in debates trying to convince others of something (which you may or may not believe in), just for the sake of practicing argumentation and logic.
  4. Good Memory
    • Use tools like Anki for spaced repetition to help remember programming concepts and details.
    • Regularly review and refactor your code to reinforce memory.
    • Practice writing code without the internet, that is without the ability to search for answers and just by relying on reading source code and remembering interfaces.
  5. Good Communication and Writing Skills
    • Write daily, whether it’s blog posts, detailed comments in your code, or personal journals.
    • Read technical documentation and learn from well-written examples to improve your own writing skills.
    • Read a book or too on English grammar and copywriting.

By consciously working on these traits, a software engineer can enhance their effectiveness, productivity, and ability to contribute significantly to their team and projects.

Adding constraint on a foreign key with node-pg-migration

node-pg-migration is a useful library. You can add a constraint of a foreign key with a simple references property on the column. For example, you have table client_session with publishable_key column and you want to reference publishable_key column in workspace table where it is not a primary key (just a unique key). The following usage with object: schema, name, won’t work:

 pgm.createConstraint({
    schema: "seam",
    name: "client_session",
  }, "client_session_publishable_key_fkey", {
    foreignKeys: {
      columns: "publishable_key",
      references: {
        schema: "seam",
        name: "workspace",
      },
    },
  })

 If you write a migration for Postgress and Node.js using node-pg-migration (e.g., table 1) and want to create a foreign key reference / constraint (createConstraint or references on createTable) on a non-primary key of the other table (table 2), then references by an object containing schema and table name, do not work. This is probably a bug in node-pg-migration. It tries to match primary keys only, but our publishable_key is not a PK in workspace.

It looks like node-pg-migration is not smart enough to add the column/field name like it does for primary keys. You can use a string (seam.table2(col)) as the references value, not an object, or just use raw SQL to bypass node-pg-migration behavior, e.g.,

 pgm.sql(`
    ALTER TABLE seam.client_session
    ADD CONSTRAINT client_session_publishable_key_fkey
    FOREIGN KEY (publishable_key) REFERENCES seam.workspace(publishable_key);
  `)

Or in the node-pg-migration method:

 pgm.createConstraint({
    schema: "seam",
    name: "client_session",
  }, "client_session_publishable_key_fkey", {
    foreignKeys: {
      columns: "publishable_key",
      references: "seam.workspace(publishable_key)"
    },
  })
},

How to show all constraints on a Postgres table

I recently needed to update the check constraint on a Postgres table column. This check does format validation similar to regex. This check was part of the CREATE TABLE statement meaning it was created with the table.

However, ALTER COLUMN is not supporting updates of checks. So what we need to do is to drop the constraint and create a new one. dropConstraint requires the name of the constraint, but the name is not obvious. This is because check was create with createTable. To find the name, there’s a SQL query we can run:

SELECT con.*
       FROM pg_catalog.pg_constraint con
            INNER JOIN pg_catalog.pg_class rel
                       ON rel.oid = con.conrelid
            INNER JOIN pg_catalog.pg_namespace nsp
                       ON nsp.oid = connamespace
       WHERE nsp.nspname = '<schema name>'
             AND rel.relname = '<table name>';

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

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 “Breaking Into IT and Tech as a Beginner”

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

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

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 “Programmer vs. Software Engineer vs. Software Developer vs. Coder”

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 “5 Reasons Programming is Awesome”

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 “My New Book Concept and Top Qualities of a Good Software Engineers”

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.

Why Blockchain is the Future, What is Bitcoin and How to Invest and Short It and Why Ethereum Is Better than Bitcoin in 1000 Words or Less

Bitcoin price was rising like a crazy and that’s why more and more people are interested in it. I did my informal survey every time I was at a restaurant or taxi by asking waiters and taxi drivers if they invested in Bitcoin. Most of them said no or “what is bitcoin?”, so this article is for them.

Continue reading “Why Blockchain is the Future, What is Bitcoin and How to Invest and Short It and Why Ethereum Is Better than Bitcoin in 1000 Words or Less”

7 Tech Job Which Don’t Require Coding

Technology is the fastest growing sector in the job market. Software, cloud and automation replace traditional jobs of factory workers, secretaries and service workers. Software and technology companies are the most valued by the stock market and investors. Founders of these companies are one of the richest people in the world. Startup founders and nerds are new role models for kids.

But what if you are not coding prodigy like Mark Zuckerberg or Bill Gates who started coding in their teens. What if you don’t really enjoy coding that much or maybe you are more of a peoples or a liberal arts type of a person? Do you prohibited from a tech industry? Most people don’t know that they are plenty of jobs in the tech industry which do not require coding.

Of course, you cannot be a clueless pumpkin and know nothing about tech. You still have to be technically literate and know what is a database or an API is, but you’ll mainly be leveraging your existing skills from another industry, not starting from a scratch learning coding. (Learning coding when you are in 50s are still possible. I saw it happen a Hack Reactor where I taught. But let’s admit, on average the wits become duller with age, not sharper.)

Here are seven (7) such jobs which do not require coding or deep technical expertise but can be interesting, fulfilling, and well-paid.

  1. Program Manager
  2. Product Manager/Owner
  3. Scrum Master
  4. Designer
  5. User Researcher
  6. Recruiter
  7. Tech Writer

Let’s me give you some brief insight into each of them.

Continue reading “7 Tech Job Which Don’t Require Coding”

Ideal Technical Interview for Software Engineers

Here’s an ideal I strive to achieve when I conduct technical interviews for software engineering positions.

  • I start with introducing myself
  • I provide a take home assignment instead of making people perform coding at the interview and, what’s even worse, on a white board instead of a computer.
  • I ask attitude questions more than skill questions to see if a person has the right mentality to learn and solve problems instead of just knowing certain skills. There’s a good book called Hiring for Attitude.
  • I dig deeper into what exactly the candidate’s role were in his/her prior projects.
  • I ask questions which are closely related or mocking the real work situation for this position. For example, a member of the Capital One Tech Fellows Program is often asked why X is better than Y or what framework should we use in our new project.
  • I leave enough time at the end of the interview to answer candidate’s questions about the role, team and the company or anything else they want to ask
  • I say a few things to create enthusiasm in this role and possibilities

In an ideal tech interview, you would just skim through the candidate’s code on GitHub, chat about recent happenings around the tech you use, and talk about life. That’s it. You don’t even need a resume in most cases. LinkedIn has the job history and GitHub (or HackerRank) is a living (almost fool-proof) evidence of the skills.

 

On Managing: The Main 3 Areas to Focus On

The more I work in tech, the more I see the most successful management being at the core about these three separate and often conflicting areas:

  • Company: Contributing to your companies bottom line by understanding the business value and long-term strategy
  • Customers: Taking care of your costumer by delivering product they want and love
  • Culture: Growing your engineers as well as positively impacting engineering culture in the company as a whole

At the intersection of these areas, there are two often conflicting axis which create a healthy push and pull if used with a right balance:

  • Short-term vs long-term, e.g., delivering projects on time vs. doing what will scale better in the future
  • Us vs. them, e.g., caring about your team vs. company or the entire engineering population

A good manager in the information-based working environment will find a way to combine the aforementioned areas and axis to form a win-win situation. It’s not always possible, but I find that it’s possible more often than not when I just push a little bit more and don’t give up early, when I try to come up with just one more creative solution.

PS: To continue musings, there are two books on the topic worth mentioning. I wrote a short summary on one of them which is called Managing Humans. I really liked that book, but recently I read another book called The First-Time Manager which seems to be the source of inspiration for Managing Humans, to put it mildly. I’m not accusing the author of Managing Humans in plagiarism, but I had a strong feeling of deja vu. It felt like Managing Humans borrowed the outline and a lot of ideas and concepts from The First-Time Manager. Interesting…. So go for “original” (The First-Time Manager). It’s not as specific and tailored to software engineers but a useful perspective. Then follow up with The 48 Laws of Power for a completely different view. :)

One Technique Guaranteed to Improve Your Coding Skill 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

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 “On Tech Leadership: Managing Humans Summary”

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 “Beautiful Node APIs”

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 “10 Things You Should Stop Doing When Giving a Conference Talk”