Just another career path

As a software engineer, I recently have heard of a lot of feedback from my colleagues and friends that they don’t see their career path or they don’t know how to move to the new levels in their company. No exception, I used to have that thinking before.

In my opinion, there is a very important reason why people are struggling to find the answer because “career path is not always the job titles”. Normally, each company has its own job titles such as junior-level developer, middle-level developer, senior-level developer, teach lead, software architect, CTO, etc. Hence, it is not true that a job title is reasonable for every company.

The interview is often conducted hardly to find a candidate matching the company title. If we have a good enough job title standard, the interview would take place very easily, right?

Therefore, I prefer to define my own career path through what skills are gained under a job title.

But wait, why do I need a career path?

To me, a career is an indispensable part of my life (and anyone else, sure?). My career path helps me visualize the big picture which motivates me to focus on the right track to achieve my next level. After all, a good career should bring me the fullest life having the following conditions:

It gives me a chance to indulge my passion
It gives me a chance that my contribution is appreciated
It gives me a chance to earn good enough money

Anyone should have their own career path, here is mine:

I see each level as a step of a ladder. It is very risky to skip any step. It doesn't mean that you delay getting to know what to be learned in the next steps. Don't let it be a black box and then get "surprise!". For example, to achieve my long-term goal as an intrapreneur/entrepreneur, I don't run a business now but I keep practicing as it a real business when building side projects with my friends.

Detail of level in my career path

No matter what the job title is, I categorize a level by the following criteria:

👷 Project/Product contribution
✋ Ability to lead and mentor the team
🕑 Years of working experience

	Who are they?	Get recognized (example)
Apprentice	Try to do things right	👷 Learn how to use tools ✋ Learn to collaborate well with other members 🕑 Usually 1 - 3 years
Journeyman	Keep doing the right things right	👷 Know how the used tools work ✋ Collaborate and cover/mentor some members well. 🕑 Usually 3 - 5 years
Master	Keep doing the right things better	👷 Know how to build a tool ✋ Lead and mentor some teams 🕑 Usually 5 - 10 years
Intrapreneur or Entrepreneur	Turn off the old and create new right things	👷 Innovate tools ✋ Lead and mentor the whole department/company 🕑 Usually 10 - xx years

Set up a web server for learning HTTP headers

Motivation We all follow the client-server model using the HTTP protocol for most of our web apps today. In development, we simply may have a backend API server and a frontend (web pages or mobile apps) only. However, it seemed that a proxy server is always required for production. In fact, most of the hardest issues in production come from integration. The requests and responses might be modified by the proxy server. Therefore, the understanding of HTTP protocol is one of the key skills to resolve those issues. I wanted to dive deep into HTTP with some core concepts such as caching, cookies, and CORS. I didn't intend to go quickly rather than moved slowly to have a well understanding of what I do. Prepare a server The easiest way is to use my laptop as a server then I can just use "localhost". I can also use ngrok to make my web server online. Finally, I use an online tool such as RedBot to check the HTTP headers. To make it more excited though, I deployed the app on A...

The power of acceptance test

User Story is the place PO gives his ideas about features so that developers are able to know what requirements are. Acceptance tests are these show the most valuable things of the features represented by some specific cases. Usually PO defines them, but not always. Therefore, refining existing acceptance tests – even defining new ones that cover all features of the User Story must be a worth task. Acceptance test with Given When Then pattern If we understand what we are going to do, we can complete it by 50% I have worked with some members those just start implementing the features one by one and from top to down of the User Story description. Be honest, I am the one used to be. What a risky approach! Because it might meet a case that is very easy to miss requirements or needs to re-work after finding any misunderstood things. I have also worked with some members those accept spending a long time to clarify the User Story. Reading carefully of whole User Story by defining...

What the heck is Meteor DDP?

I was using Meteor for my messenger project. I was so curious about the real time connection. I wanted to know how exactly this mechanism works. In this post, I will go through the DDP Specification, an overview of WebSocket, and a simple demo about how to subscribe a publication of Rocket.Chat (containing a DDP server) from an external webpage. At a glance, I knew that Meteor invented a protocol called DDP which uses for handling real time connection. So then, what is DDP? "DDP (Distributed Data Protocol) is the stateful WebSocket protocol that Meteor uses to communicate between the client and the server." [1] All right! Why does DDP matter? "DDP is a standard way to solve the biggest problem facing client-side JavaScript developers: querying a server-side database, sending the results down to the client, and then pushing changes to the client whenever anything changes in the database" . [2] In order to understand deeply the protocol, I decided ...

DevOps Toolchain Enhancement

Historically, our company ubitec had started with a customer project. Agile/Scrum was our proposal for working with customers. Time by time, Agile/Scrum also became our culture for software development. To be successful with this development approach, we somehow needed to have a fast release for customers (i.e. every one week). Back then, we had a build tool Jenkins which was responsible for having sprint release packages for our customers. The build job pipelines contain some steps such as gathering the artifacts, checking the code convention, running the tests, building docker images, and packaging an archived file (a zip file). The set of tools involved in a pipeline is roughly called a toolchain. It is just a part of a bigger process called the DevOps toolchain. Source: https://www.ibm.com/blogs/cloud-archive/2016/11/devops-architecture-available-on-bluemix-garage-method-site/ DevOps is a proven method that fits Agile. Today, it is even treated as a mandatory factor...

Solving your data visualization needs with open source reporting

Most of applications have some types of data visualization needs: - Gather the data. - Perform calculation, sort, group, aggregate, total,.. - Present information professionally. and meeting user demand is crucial to the success of an application. To solve this problem, there are some different approaches: - Buy a closed-source commercial product (for example, Crystal Reports, JReport,..), we must to pay for a lot of features but maybe more of features we don't need. - Build a custom-developed solution, so we need a team to develop our solution but the problem is how much time and money that we need to spend for that. Nowaday, open source creates new choices. Firstly, we can leverage open source in a customer solution by plug-in it to our solution. Secondly, we can build open-source-based products by using open source code. There are many open source reporting tools for use in the enterprise such as BIRT, iReport, JasperReports,... In this post, I wou...

vhandit

Search This Blog