Showing posts with label Mentoring. Show all posts
Showing posts with label Mentoring. Show all posts

Tuesday, January 2, 2024

Review of 2023 & plans for 2024 as a software engineer

A review of last year and plan for 2024 except anything from the day job.

2023 - What was planned with status

Goals

  • Continue
    • ✅Python - Continue learning.
      • Converted my own utilities to Python. Now my first preference coming to mind is Python.
    • ❌WebAssembly - Continue learning including WASM containers
    • ❌Pass the AZ-304 exam. Continue learning Azure computing.
    • ✅Continue making 1 blog post per week.
    • ❌At least 25% or more posts to be videos
    • ❌Achieve 250 subscribers in my coding YouTube channel Joymon v/s Code. 
      • Just crossed 100 only.
    • ✅Monthly 1-2 hours for personal projects
  • New
    • ✅Set up the Ethereum blockchain and write one smart contract
    • ❌Spend 3 hours every week on LinkedIn Learning
  • Experiments
    • ❌The big thing would be an attempt to present a topic in a public event conducted by user groups.
    • ❌At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
    • ❌Write my own GitHub action.
    • ❌Write a test Telegram/Discord bot
    • ❌Write a test Flutter app

What I am not going to do

  • ✅Blockchain coding - expertise.
  • ✅Go & Scala - watch some videos. Not in deep.
  • ✅Data science algorithms.

Additional achievements

  • A beginner stage in new buzzword generative AI.
  • Hands-on experience with Ansible by automating home nas on Raspberry Pi.
  • Deep dive into some of the Kubernetes features and Windows containers
  • Deep dive into SharePoint Online, and Office Online.
Overall it could have been much better. The meaningless excuse I am telling myself is that my spouse started working hence I have very minimal time for extra activities.

2024 - What is ahead

Goals

  • Continue
    • Continue Python
    • WebAssembly - Learn WASM containers.
    • Continue making 1 blog post per week. Out of that, 15 or more posts are to be videos. 
    • Achieve 500 subscribers in my coding YouTube channel Joymon v/s Code.
    • Monthly 1-2 hours for personal projects
    • Intermediate level in generative AI
  • New
    • Same as last year, a big thing would be an attempt to present a topic in a public event conducted by user groups.
    • At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
    • Write my own GitHub action.
    • Write a test Telegram/Discord bot.
    • Write a test Flutter app.
    • Teaching my kids how to think like programmers. Python for the 4th grader and Scratch for kindergartner.
  • Experiments
    • Automate YouTube video production via AI tools.
    • A blockchain app prototype.
    • Try to do a Scratch or similar technology video with my kids.
    • Experiment with the 3D printer at our public library and printing technology overall.

What I am not going to do

  • Blockchain coding - expertise.
  • Go & Scala - watch some videos. Not in deep.
  • Data science algorithms.

Tuesday, January 10, 2023

Review of 2022 & plans for 2023 as a software engineer

A review of last year and plan for 2023.

2022 - What was planned with status

Goals

  • Continue
    • ✅Linux - Install personal laptop to Linux and build expertise
    • ✅Python - Continue learning to become intermediate level.
    • ❌Pass the AZ-304 exam. Continue learning Azure computing.
    • ❌Continue making 1 blog post per week.
    • ❌At least 25% or more posts to be videos
    • ❌Achieve 250 subscribers in my coding YouTube channel Joymon v/s Code.
    • ❌Monthly 1-2 hours for personal projects
  • New
    • ✅WebAssembly - Try out apps
    • ✅Blazor - Learn basics
    • ❌Set up the Ethereum blockchain and write one smart contract
  • Experiments
    • ❌The big thing would be an attempt to present a topic in a public event conducted by user groups.
    • ❌At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
    • ❌Write my own GitHub action.
    • ❌Write a test Telegram/Discord bot
    • ❌Write a test Flutter app
  • Not going to do
    • ✅Blockchain coding - expertise.
    • ✅Go & Scala - Maybe watch some videos. Not in deep.
    • ✅Data science algorithms.

Additional achievements

  • Deep dive into some of the Kubernetes features and Windows containers
  • Working with SharePoint Online via Graph API as well as SharePoint APIs and different SDKs
Overall the year 2022 was hijacked by house buying leaving fewer achievements as a software engineer.

2023 - What is ahead

Goals

  • Continue
    • Python - Continue learning.
    • WebAssembly - Continue learning including WASM containers
    • Pass the AZ-304 exam. Continue learning Azure computing.
    • Continue making 1 blog post per week.
    • At least 25% or more posts to be videos
    • Achieve 250 subscribers in my coding YouTube channel Joymon v/s Code.
    • Monthly 1-2 hours for personal projects
  • New
    • Set up the Ethereum blockchain and write one smart contract
    • Spend 3 hours every week on LinkedIn Learning
  • Experiments
    • The big thing would be an attempt to present a topic in a public event conducted by user groups.
    • At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
    • Write my own GitHub action.
    • Write a test Telegram/Discord bot
    • Write a test Flutter app

What I am not going to do

  • Blockchain coding - expertise.
  • Go & Scala - watch some videos. Not in deep.
  • Data science algorithms.

Tuesday, April 19, 2022

Best developer to better software engineer

If we google how to become a better developer and increase the code quality, we can see a lot many links. For example, X number of ways/tips to become a better developer. Mainly having the same tips explained differently. Write unit tests and write readable code to name a few.

Writing better code makes us better software engineers? 

Software engineering has many aspects other than good code. There are many parties involved, such as the sponsors and stakeholders, actual users, support teams, infrastructure teams, security teams, etc. Also, the managers who bridge between developers and business are crucial. To become better engineers, we need to work better with them. 

Below are three golden steps to becoming a better software engineer. Those are useful, especially in this agile world. We can repeat the steps for the entire system if it is small, or for each feature, we are adding to the existing system.

Each step can include some activities.
  1. Get it done
    1. The aim is to get the working code to get attention.
    2. Use wireframe before writing code.
    3. Show demos. Do not release the code.
    4. Recommend to follow TDD from here itself. The target of 50% test coverage but not mandatory.
    5. Get early feedback.
    6. Can use copy-paste coding without understanding how it works.
  2. Get it right
    1. At this step, we should be having confirmed projects or features, so refactor to readable code.
    2. Patterns such as DI. Make code SOLID.
    3. Complete API specs
    4. Strive for 100% test coverage though it's a dream.
    5. Ensure security, basic performance, etc...
    6. Do not copy-paste code. If you are forced, understand after pasting it as it is our code.
    7. Release the versions to production in this step.
  3. Get it optimized
    1. Increase the performance and scalability.
    2. Do not change anything without proper test cases.
    3. Get feedback from support and address their pain points.
    4. Learn from production logs, usage stats, etc...
This works great with the products. For service organizations, it may be different. They may be looking more at the "number of features to money conversion" ratio than the final product. A demo may be promoted to production. In such circumstances, avoid the first step (Get it done). Do it the right way from the very first step, even for a demo or PoC (Proof of Concept). Otherwise, we may lose our sleep, weekends, and holidays. Finally, it will be difficult to advance in our career path.

Should we say goodbye to code quality?

Still, code quality is important. As coding has an art element in it, we should always improve its quality and its never-ending process. Remember, the code is never written forever. There will be fellow developers maintaining it in the future. We should not make their lives difficult. Along with execution, readability to fellow developers is also important. 

If we look at the code we wrote 6 months ago, we find a couple of ways to improve the code quality. 

One easy way is to look at others' code on GitHub or in other tracks in our projects. Reading books will also help improve coding quality. It is very difficult to get all the things right on the first read. So read it again...

Become a better debugger by increasing debugging skills

Coding is something very complex that a human brain can do. Our brains are not evolved to code. It is difficult when we need to deal with a lot of states (variables). Also, keeping track of their values at various levels of execution is tedious. 

If we want to become better developers, we should also become better debuggers. We should be capable of avoiding debugging in the first place by planning. To be frank, I am not able to reach that level. Increasing our debugging skills is very much required. 

Below are some links to help us improve our debugging skills. This includes a free course on systematic debugging.

Reference 

Happy engineering...

Tuesday, January 11, 2022

Review of 2021 & plans for 2022 as a software engineer

The usual procedure continues. Reviewing last year and planning next year.

Below are the goals from 2021 as published last year with status.

2021 - What was planned

Goals

  • Continue
    • ✅Focus on containers and K8s hands-on.
    • ✅Pass the AZ-303 certification
    • ✅Linux - Become an intermediate level knowledge
    • ✅Continue to learn more and more enterprise practices. Including infrastructure concerns to understand how to run production systems than just building those
    • ✅Continue making 1 blog post per week.
    • ❌At least 25% or more posts to be videos
    • ❌100 subscribers in my coding channel Joymon v/s Code.
    • ✅Monthly 1-2 hours to personal projects
  • New
    • ✅Learn Python language. The goal is to reach an intermediate level
    • ✅Build experience in Unified .Net platform.
  • Experiments
    • ❌The big thing would be an attempt to present a topic in a public event conducted by user groups.
    • ❌At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
    • ❌Set up a blockchain and write one smart contract
    • ❌Write my own GitHub action.

Additional achievements

  • Architected microservice-based applications that are getting deployed to Azure Kubernetes Service.
  • Migrated my personal website https://joymononline.in/ to JAMstack architecture based on  Hugo from AngularJS.

What I was not going to do

  • ✅Blockchain coding - expertise.
  • ✅WebAssembly - Maybe watching some videos. Not in deep.
  • ✅Go & Scala - Same as web assembly.
  • ✅Data science algorithms

2022 - What is ahead

Goals

  • Continue
    • Linux - Install personal laptop to Linux and build expertise
    • Python - Continue learning to become intermediate level.
    • Pass AZ-304 exam. Continue learning Azure computing.
    • Continue making 1 blog post per week.
    • At least 25% or more posts to be videos
    • Achieve 250 subscribers in my coding YouTube channel Joymon v/s Code.
    • Monthly 1-2 hours to personal projects
  • New
    • WebAssembly - Try out apps
    • Blazor - Learn basics
    • Set up Ethereum blockchain and write one smart contract
  • Experiments
    • The big thing would be an attempt to present a topic in a public event conducted by user groups.
    • At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
    • Write my own GitHub action.
    • Write a test Telegram/Discord bot
    • Write a test Flutter app

What I am not going to do

  • Blockchain coding - expertise.
  • Go & Scala - Maybe watching some videos. Not in deep.
  • Data science algorithms.

Tuesday, January 5, 2021

Review of 2020 & plans for 2021 as a software engineer

 As I do every year, this time also I did the review of last year and planned the new year 2021. That said, this is not a technical post. Rather it's my own reflections of last year and plans about next year related to my technical life. I was doing this privately from the beginning of my career. Last time onwards making it public.

Below are the goals from 2020 as published last year with the status marked 

2020 - What was planned?

  • ✔️Focus on cloud computing, containers & Kubernetes.
  • ❌The big thing would be an attempt to present a topic in a public event conducted by Microsoft user groups.
    • There were virtual meetups. So Covid-19 is not an excuse
  • ❌Pass the AZ-300 certification.
    • Learned a lot
  • ✔️Linux - mainly for the container world. At least change home machine to Linux
    • Got Raspberry Pi 4 and it is running as Home NAS using Linux-based Raspbian OS.
  • ✔️Taste the feel of real micro-services and serverless in at least one application.
    • Not a big scale but there are some.
  • ✔️Learn more and more enterprise practices. Including infrastructure concerns to understand how to run production systems than just building those.
    • Good exposure with the disaster recovery space.
  • ✔️Continue making 1 blog post per week.
  • ✔️At least 25% posts to be videos.
  • ❌At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
  • ✔️Monthly 1-2 hours to personal projects
    • Converted my personal portfolio site to JAMstack technology using Hugo. It is deployed.
  • ✔️Some experiments with IoT boards.
    • Raspberry Pi 4 board basics

Additional achievements

  • Learned Hugo a static site generator for JAMstack
  • Automated the setup of dev machine using Chocolatey
  • GitHub actions. Just consuming. Not yet created one.

What I am not going to do

It is essential to decide what to avoid in this world of drastic changes and fancy technologies
  • ✔️Blockchain coding - Oh this thing is getting postponed 3rd year.
  • ✔️WebAssembly - Maybe watching some videos. Not in deep.
  • ✔️Go, Scala & Python - Same as web assembly.
A tick mark here indicates I was successful in controlling myself to stick with the plan. Nothing or did very little as planned.

2021 - What is ahead

Goals

  • Continue
    • Focus on containers and K8s hands on.
    • Pass the AZ-303 certification
    • Linux - Become an intermediate level knowledge
    • Continue to learn more and more enterprise practices. Including infrastructure concerns to understand how to run production systems than just building those
    • Continue making 1 blog post per week.
    • At least 25% or more posts to be videos
    • 100 subscribers in my coding channel Joymon v/s Code.
    • Monthly 1-2 hours to personal projects
  • New
    • Learn Python language. The goal is to reach an intermediate level
    • Build experience in Unified .Net platform.
  • Experiments
    • The big thing would be an attempt to present a topic in a public event conducted by user groups.
    • At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc.
    • Set up a blockchain and write one smart contract
    • Write my own GitHub action.

What I am not going to do

  • Blockchain coding - expertise.
  • WebAssembly - Maybe watching some videos. Not in deep.
  • Go & Scala - Same as web assembly.
  • Data science algorithms

Thursday, August 27, 2020

[Video] Think before start coding to automate your next task

We as developers tend to automate our tasks without thinking much. Sometimes it would take more time than doing it manually. Obviously, automation gives us better accuracy but it is good if we know what is the Return on Investment Before we automate our next tasks.

Watch the video for further details.

References

https://www.youtube.com/watch?v=D80GucAAD4c

Tuesday, December 31, 2019

Review of 2019 & plans for 2020 as a software engineer

Let me state the disclaimer that this is not a technical post. Rather it's my own reflections of last year and plans about next year related to my technical life. I was doing this privately from the beginning of my career. This time thought of making it public

2019

Achievements


  • vlogging - The biggest achievement of the year was the start of vlogging. I started my first video tutorial with 'text to speech' instead of my voice. But later got the courage to publish in my own voice. 
  • Blogging - Also, mostly able to keep up one technical post per week.
  • Performance optimization - Refreshed application performance optimization skills. Learned new techniques. 
  • Power BI - I learned Power BI and created a dashboard for analyzing IIS logs. Power BI was postponed by me as it was not having much programming elements. Now I understood why everybody going behind Power BI.
  • Containers - Though I had blogged about container technology from the very beginning, I never got enough hands own experience. This year I got a good amount of hands-on time. To be frank, not able to get hold of Kubernetes yet.
  • Azure - Conscious efforts were put forward Azure during the year. Though not able to achieve the goal of passing the Az-300 exam, I prepared a lot for it. The immediate aim in 2020 would be to pass the same.
  • Public events - Similar to previous years attended public events mainly conducted by the Microsoft user groups.
  • Coding diagrams - The next big thing I learned and practiced was coding diagrams using PlantUML. Easy to deal with diagraming as an architect.
  • Interviews - I was nearly taking 3 interviews per week. Mostly Solutions Architects and cloud specialists. It again enforced my perception that to continue working as Solution Architect in US one doesn't need to be hands-on. But should be a salesperson with a basic / breadth understanding of concepts. There were cloud architects who kinds of started with cloud from its birthday (day 1) but never faced any cloud-specific challenge.
  • Enterprise Architecture - It is the year I was slowly getting converted from Solutions Architect to Enterprise Architect or at least had to deal with enterprise architecture. More time I am spending on Enterprise concerns such as protocols, OS versions, HA & DR, AD, AAD, wire sharking than designing solutions. Though I did some solution designs, those were more towards non-functional such as security & infrastructure-related than application functionalities.

2020 - What is ahead?

  • Focus on cloud computing, containers & Kubernetes.
  • The big thing would be an attempt to present a topic in a public event conducted by Microsoft user groups.
  • Pass the AZ-300 certification.
  • Linux - mainly for the container world. At least change home machine to Linux
  • Taste the feel of real micro-services and serverless in at least one application.
  • Learn more and more enterprise practices. Including infrastructure concerns to understand how to run production systems than just building those.
  • Continue making 1 blog post per week.
  • At least 25% posts to be videos.
  • At least 10% posts to external sites such as CodeProject, DZone CSharpCorner, etc..
  • Monthly 1-2 hours to personal projects
  • Some experiments with IoT boards.

What I am not going to do

It is important to decide what to avoid in this world of drastic changes and fancy technologies
  • Blockchain coding - Oh this thing is getting postponed 3rd year.
  • WebAssembly - Maybe watching some videos. Not in deep.
  • Go, Scala & Python - Same as web assembly.

Updates

2020-01-03

Removed work-related references - There is a policy in my current organization that "employees MUST not identify himself or herself as an employee of the company in a blog or on a social networking site". Though I was not using the company name in this post, people were able to identify. Thus removing the work-related references from this post.

Tuesday, January 17, 2017

The great developer divide

This will be non interesting to someone who is looking for code snippets. This is gonna kind of theory or history class with some predictions. As always predictions may come true not guaranteed. Lets come to the point. What is meany by developer divide? In simple sense, the developers are going to be divided into 3 species.
  • Application integration developers
  • AI / Algorithm developers
  • System / infrastructure developers
    • Cloud  developers  - includes device driver writers.
Before we think oh there are already 2 groups of developers and are named the same for at least last 10-15 years. What is new?

Evolution in Biology

Lets look at how new species are evolved in biology. If you are an opponent of evolution, you may better stop reading as without understanding the biological evolution, its difficult to understand any evolution including the formation of new languages and all. In biological evolution when some group does different things than the other group of same species or they are separated geographically a new species is formed. If the divide is for small amount of time, they can mingle together and continue as one species. In the other case, there will be 2 species.
Another reason for survival or destruction of species is the ability to suit to the environment. For example, consider the famous evolution scenario explained in England related to industrial revolution.
This is kind of easy and old explanation. The real reason is the gene mutation, which goes to the next level. Only the members who got useful gene mutations will produce more off springs and after a long time they becomes new species which has clear distinction from the old.

Characteristics of these developer species

Coming back to the software, what are characteristics of these new species.

Application integration developers

These are the majority of developers. They write applications which accepts data from user and store somewhere. When user wants the data they just show them or send to them periodically by means of some push mechanism, Some transformations on the data will be done by them which are more towards formatting the data. They never create new data ie knowledge from the data except generation of logs.

More importantly this species of developers will be vanished or become low profile when other species of developers become stronger. It will be difficult for these application developers to convert to the other species though some may succeed and survive. Whatever these developers were doing will become a task of business people. For example business analyst will be able to assemble applications and do most of the customizations. 

Currently there are some environments where we can see this is happening. Visual Studio LightSwitch is one to name.

AI / Algorithm developers

This species will write complex algorithms and expose them as service with the help of infrastructure developers. Application integration developers will consume the algorithms written by this group before they get extinct with the invention of AI programs which does coding.

This type of developers will be high profile, high in number and gets job safety for longer time. They will be knowing basics of application integration but never know what and how the infrastructure developers work.

We can see examples already such as Algorithmia, Azure Machine learning etc...

System / infrastructure developers

This species will know how to deal with the bare metal machine whether it is silicon based or quantum based even carbon based biological machines. They cleverly abstract the hardware from the application integration developers and AI developers.

There will be less number of developers in this species. They control most of the things. They may consume the algorithms written by the other species without knowing how its done.

Reasons for this prediction.

No one can just predict something and run. They should have some kind of reasons for the prediction.

Bare metal is going away from developers

This is something everyone is agreeing now a days. There are many many abstractions coming over the hardware and the main reason is to code once and run everywhere. Another reasons we can hear is the reusability, less development cost etc...

Frameworks

When we were developing for Intel 8085, we had to know what are the CPU registers, their size, memory addressing and port addresses. Now if we ask how many registers are there in the CPU to a new gen .Net or Java or JavaScript developer, they will not have any clue. If we further go back in time, we know there was punch cards and developers had to know so many mechanical & electrical properties of the system. After 8085 days, we got assemblers, compilers and we entered into managed world.
Now from the managed world we are going to the world of integration. Connect some dots and the software will be ready. Even for device programming JavaScript is used which completes the story.

Cloud is abstracting

Another abstraction is happening in the distributed systems world. Distributed means something which is done with 2 Turing machines. or somewhere data is serialized and passing through. Cloud started slowly with IaaS where we got virtual machine. Then came PaaS where we don't need to worry about machines anymore. It is now reached to FaaS where each function is a service and can be deployed independently. Another sweet name is Serverless. Now people are telling that though the name Serverless, there are servers underneath but developer don't need to worry. 

But think of a time where the underlying machine is a quantum biological computer. Still we can call it a server but the underlying system has completely changed and there will be no clue to the consumers how the FaaS executes code.

AI Algorithms are too complex to be understood by all

Earlier colleges were teaching sorting and searching algorithms. But people who studied those were not coding those algorithms everyday as those came as part of the standard libraries. That helped the developers concentrate on the real business problem. That is good. After those days the business requirements got a new face of data analytics. Everyone wanted to analyze their data. Some at least know what they want from data. Some are just fiddling with data for treasure. That brought a good momentum to the field of algorithms. Many algorithms were developed but the same question came again. Should we just consume those algorithms like how we are consuming sorting and searching or should we learn those algorithms. Obviously the route is same. The consumption. 

Another reason is their complexity. It is very difficult for normal application developer to know how face recognition algorithm works as it requires prior knowledge in different fields. So the consumption is easy. This eventually boosts the developer divide.

There may be many more reasons which are not listed here. However the developers are getting unavoidable division which occur in every growing science and technology fields. The best practice is to select own field and be an expert in it.

Thanks for reading.

Tuesday, September 27, 2016

From Application Architect to Consultant Application Developer

To be frank, this is not a technical post. May be first post in this blog without any code snippet.

Let me start with a quote.

"A developer can be CTO, if he switch from Google/Facebook to a personal portfolio site building company"

People may disagree to this as CTO position needs more skills than a hardcore smart developer. This is from my experience with the industry. Technical positions depends on nature of work especially how critical the projects are. We can see people doing coding only in mission critical applications/frameworks who gets more money than a CTO of portfolio web site development company.

This post is regarding my job and role change from Application Architect to Consultant Application Developer. The above is not to get a self satisfaction by saying its common:)

What I was doing earlier

By title I was Application Architect. But due to the nature of company or nature of me, I was doing developer++ jobs along with some architectural jobs such as preparing the technical arch document, leading the technology and cultural(At least sone amount of TDD) changes.

Why I change

I understood that Application Architect is not developer++. That is a different role requiring different skill set and mind set though development skills are very important.

Does the arch do estimations? I was thinking no. But now I understood that archs needs to do estimations at least high level as in the beginning of the projects only architects know what and how exactly the technical things are going to be.

During my arch role I strongly believed as an arch I should never draw some boxes and run away. Instead I should make sure the project is delivered in quality at all the levels. The challenging part was code quality. I had spend too much time to ensure the project has good code quality and because of that I was not able to give attention to many other areas. I took that as a challenge to bring code quality to a culture which built around the core principle of "deliver on time even if its 0% quality". Later I understood, there is no meaning in giving something which is not needed by the stakeholders/sponsors. More than that if we want to bring code quality, it should be a mission critical project where failure in the application will halt the business. But the advantage of working in just-deliver projects is a kind of job safety.

When I do code reviews, I felt sometimes the team members are not comfortable especially when I ask why this is class level variable or public? They started murmuring that I am also like other high level managers who don't know or forget coding and not able to understand developer feelings.  I became tech lead at the experience of 3.5 Yrs and arch at 5.5 Yrs. I feel it was too quick and may be I missed the developer days and that is the reason why I am not able to understand their feelings. There is no chance to get the developer days back in the current company from the arch position because there are no mission critical or real critical frameworks.

Offshoring is a great way to reduce cost for developed countries and its good for countries which gets new jobs. I was in offshore for long getting more money than my friends working for business / companies. But its little tedious when comes to onsite and deals with offshore teams. We have to make sure offshore is happy without reducing productivity. It can only be achieved by frequent interactions. Due to the timing(East cost US and India), either I had to spend my night time or they have to spend their night time to get enough 1-2 hrs interaction per day. Some companies do understand that when they do offshoring for low cost, the quality will reduce and time will increase. But some won't. Then the trouble starts. If we want to get things done next day by offshore, offshoring doesn't looks great to both the sides though what ever relation is there among the team. 

Should the architects give more important to coding or meetings and other things? My understanding was arch should eliminate most of the meetings as they are technical persons and focus only on tech stuff. But its not true. Architects should be able to sell what he done and that can only be done by meetings and other inter personal skills.

Of course money was also involved. When a company bring people to US from outside, there is a  tendency to give the minimum required to process the visa regardless of their importance or role. There are a good chunk of people who thinks their destiny is to reach US and they will stay back in whatever salary is offered at first. At least until they get green card. But I am not in that category.

The good thing here in US is, there are so many resources available such as glassdoor.com which gives a good idea about market rates. Since black mailing my company with a resignation letter for more money was not my way, I decided to move out. May be in future, if there are convincing reasons will join back.

Everything needs a last fire to start. In my case there was a fire. From the beginning of my career at the company, I was busy with tasks one after another. The situation was like if I quit, company will impact. As a professional I never wanted to give such an impact. But recently one of the flagship product's AngularJS conversion project was taken out from me when the first phase is about to complete. This gave a good gap to say bye without impacting the company. Till this time I never received any call about any issue / query in the project. From that I believe I neved created any dependency on me and I did the proper documentation. Or the person who took over the project or my team is really great and they can manage themselves.  

What I do now/What I gained

Pure development for mission critical application(s). Every variable and line counts. No line will be checked in without lead's code review. If there is a build/MSI change I have to do it myself.

I am really getting the feeling from the developer side after a long time. How do they think on code reviews etc... 

If the app breaks the business will halt and it may lead to firing. No offshore calls or no need to be accountable for other person's work.Since I am consultant developer, my job is mainly to make sure my code works though I try to ensure the post coding activities are going smooth. 

I am not a critical part of the team as I am still learning the system. Hope I should be able to learn the entire system at high level with in 6 months.

There are many more learning such as how an architect should see the code quality. They should be first worried about the contracts/interfaces in the system. Let the team does the implementation. Architect should be able to design the system by contracts to split the tasks and give to team to get the rest. Some kind of piece work approach. To the extent, an architect should not ask what is the purpose of a variable if its internal to class or function. Let that be a worry for the leads who maintain that module and after getting production support calls at night they will automatically change.

Another thing is the socializing. I was in the impression that when I sent a mail with new idea everyone will read it as professionals. But it never happens unless they report to me and I have direct impact on their appraisal. As an architect I have to socialize the idea duing informal meetings and get support from all. At the end the credits to the idea may be on different person's account. But that is fine if we had sent one mail initially to the boss or publish an article in company blog:) 

What I loose

Arch position has knowledge of end to end system. What are the components and how they interact etc...Doesn't needs to go into details of application till a defect or critical situation comes. Another privilege is to take decisions and move on which gives the feeling of ownership.

Tuesday, September 13, 2016

Interviewing developers for legacy application codebase

Many of us are working on legacy codebase and cursing the previous developers for what they did? Especially on code quality. It may be very difficult to understand others code, if there are no comments or documents on why they did something in a particular way. Then we have to assume what was going on their head when they were writing that piece of code. Based on that we have to take new decisions. If our assumptions are wrong, our decision will also get wrong and it produce more damage to the system.

So to work on legacy code, developers needs special skills to read previous developers mind by looking at code. Its something like investigating a criminal case or researching on fossils to find what and why it happened in the past.

What is legacy codebase?

My simplest definition to the legacy code is as follows.

Any code which contains technical debt is legacy code.
Technical debt makes code resist to changes. Now we have to understand what is technical debt in software engineering. Its nothing but the damage caused to software because of bad decisions. One will not take bad decisions intentionally. They might be forced to take bad decisions because of many reasons. When we say taking bad decisions, it may be taken by higher managers as well as developers. Don't think that developers are not involved in producing technical debt. Below are some reasons for tech debt.

  • Deadlines because of budget, competition & time
  • Lack of analysis, planning & design.
  • Lack of awareness.
In one way tech debt is good and that is what gives job to most of us :-)

Coming back to legacy systems. If we google, we get different views on legacy code. Below are some of the factors people are saying what makes a codebase legacy

  1. The system or the target platform for code is out of common use or runs in compatibility mode
  2. The codebase contains code for handling old and outdated things such as reading floppy disk or serial port etc...
  3. The code which works in production but difficult to maintain because
    1. The original developers are not around
    2. No comments or docs.
    3. No code quality such as no inheritance & overriding, no patterns, not following SOLID etc...
    4. So many short cuts.
    5. There are many dependent systems which restrict changes
    6. The third party library versions are no longer supported by vendors
    7. No unit tests to validate new changes.
  4. Any production code is legacy
If we look closely, all these reasons points to technical debt. Ideally we should pay off tech debt at some point. But nobody does because of budget and release timeline constraints hence the code becomes legacy.
But it didn't mean we can just keep the legacy code as is and go forward. There should be somebody to maintain the legacy systems as there were good investments went to build such systems.

Also we cannot guarantee that the new systems we build will never became legacy.  

Tips to interview for legacy codebase

As we seen in the beginning engineers who are going to maintain the legacy codebase needs special skills. Below are some techniques to be tried to assess them during the interview.

Inform them

The first and important thing is to inform them that they are going to work on a legacy codebase. That gives them a chance to rethink and reject the offer. There are not many developers with the skill to work on legacy codebase. As mentioned above it requires special skill sets than just writing code. If their body language changes on hearing the word legacy systems, we need to be cautious. There are still programmers who don't know what is legacy code and of course they cannot take any action based on this information.

I was part of interviews to hire for legacy codebase and I asked about ADO.Net knowing that the person is not at all going to write any ADO.Net code.  Most of the legacy systems will be having a working data layer and developers will be getting required object(s) when they make a call to DL.Also asked about new language features knowing that its not going to be upgraded in recent years.

Puzzle to find out the logic

If the candidate is willing to work on legacy code, the next step is to evaluate them whether they are fit for the job. One of the important skill required for legacy code maintainers is the ability to understand the intention of previous coder by looking at / debugging the code. There is no guarantee that there will be enough comments, docs or best practices. So the best way to evaluate them is to show a piece of poorly written legacy code and ask to find out what is going on.

If we have legacy code, we don't have to think about what to ask. We can get it from our codebase itself. one sample is below.
int a=0;
private void Timer_Tick(object sender, EventArgs e)
{
    if ((a++ & 0x10) != 0)
    {
        Foo();
        a = 1;
    }
    DoWork();
}
 
private void Foo()
{
    Console.WriteLine("Foo");
}
 
private void DoWork()
{
    Console.WriteLine("Do Work");
}

What is happening in this timer tick event handler? Most of the graduates who just came out of college can say the output of this code. But they may not understand the thought process of the developer who wrote this code. The history goes as follows.

Developer X wrote the original code. At that time there was only DoWork(). For every timer hit, say 1 second the function was getting executed. Later developer Y came and he had to do something every 16 seconds. By that time, this code became legacy. X is not there in company or too busy to help Y. So instead of introducing new timer and all, Y simply added a counting mechanism using variable a so that only in every 16th second the Foo() gets executed. Y might have added simple comparison of variable a to 16 and reset the same.

Later Z came to fix performance with  hardcore bits and bytes computer science background and he changed the simple comparison to bitwise operation.

If somebody thinks like this, he is perfect fit for legacy systems.

Puzzle to fix something with minimal changes

Another important ability required for legacy developers is to do things with minimal changes. Better they should fix the defects by removing code than adding more. We can easily find out these type of scenarios in the legacy systems. If the candidate is able to fix by removing code, hire him immediately.

Refactoring with tools

Refactoring is important when working with legacy systems. It doesn't mean one person should sit for months and refactor entire code base. Instead whenever we do a change do a small refactor. Instead of doing it by hand, it should be done with tools such as refactor menu in Visual Studio. Testing a candidate for refactoring skill requires machine test where we can observe what is his/her approach towards refactoring. They should be refactoring only after making sure its not invoked from outside via reflection. Also look whether the names they are giving are meaningful or not. If someone don't know how to name things and refactoring, its same as creating legacy code in the first place.    

Tuesday, December 15, 2015

10 years in software industry - What I learnt?

What's this post about

As of  7 Nov 2015, I have completed 10 years in the software industry. I have started as developer support engineer and now working as application architect. Currently in my third company, working places range from Chennai, Kochi in India and New Jersey, US. Worked in products and projects. Lacks pure consulting. Technologies are mainly Microsoft, little bit of Android and HTML,JavaScript & CSS based web.

Just thought of scratching my learning and some advise to other fellow developers. These are solely my views. You may agree or disagree. Sometimes will have entirely different opinion.
  • Programming
    • Design - every programmer should create/have minimum design before typing.
      • Hardest thing in programming is naming things. Spend some time during design at least for public classes, methods etc...Private things we can change at any time to a meaningful name.
      • Do no think when coding. Do not code when thinking.
        • But these activities needs to happen in short cycles. eg: Think and design for 15mins and code for next 15 mins and commit your changes.
      • We can never build a generic generic program. If it was possible world does't had these much programmers.
      • Think about generic mechanism and patterns, if something is repeating 3 times.
      • Design API by first writing client/consumer apps. Better test from 3 different clients/scenarios before finalizing.
    • Problem solving
      • If struck on a problem for 30 mins, take a break. It will clear our bias and help to think out of the box.
      • If the above is not helping explain the situation to some one who may or may not understand software. 90% of time, during the explanation new idea will pop up in our brain. Brave people can try rubber duck debugging also.
    • Defect fixing
      • Fix code by eliminating code not by adding code.
      • More code, more defects.
      • When testing team reports a new failing combination, try to add that in unit tests when fixing.
      • There are some defects which will never get reproduced in development. But had to fix by looking/reviewing the code.
      • Always write down debugging steps, so that you can restart from where you stopped after attending call from wife or girl friend.
    • Code quality
      • There is no perfect code. After spending days to finalize one class, a new person seeing that first can suggest improvements. Need to balance to meet the release time.
      • Do not refactor for the sake of refactoring. Refactor as part of new features or defect fix. But make sure those are different commits to source control.
      • Achieving SOLID is difficult. At least make sure your functions are doing one thing and write pure functions.
      • If possible get the review done via writing unit tests.
      • During day job, often the priority goes to meeting deadlines and developer will be forced to write bad code. So develop personal projects or participate in open source projects to write perfect code where there is no deadline.
      • It is not possible to meet a deadline without any hacks. The quality should be maintained by fixing it immediately after the release. In case, its single delivery, try to fix before completion.
    • Coding practices
      • Assembly language era is over. JavaScript has got many minification utilities. So let's program for fellow developers to understand. They are going to maintain the code in future
      • There was a misunderstanding that writing unreadable, complex code will keep the job safe. But that is not true as the new generation developers are writing code way earlier than us and they are smart to take over. 
      • Keep state in one place. Make 90% of classes / code stateless.
      • Do not keep different scenarios, you thought during coding in your head. Document as test methods. Else after some months you cannot understand why you wrote.
      • Communicate what code does via proper variables,functions, classes and component(dll) names. 
      • No comments for explaining logic. This is because when next person changes the code there is no guarantee that he will update comments.
        • API documentation is fine. Eg: xml comments in .Net
    • Source control, build & deployment.
      • Commit your changes within maximum of 30 mins. If you are not able to complete something after 30 mins, go back to thinking/planning and split the tasks appropriately. First step can be creating the source folder structure / test classes and committing those.
      • Do not comment the code for using in future by uncommenting. Its there in source control. If your company is not using source control quit immediately.
  • Architecture
    • Tough task is to balance between delivery timeline and quality. Should never go to extremes.
    • 90% of the time it is not built. Its evolved.
    • Do not stop coding. If you do so your design will be just boxes to developers.
    • Spend time to validate whether code is following arch. Sometimes change arch to the way code is going.
    • Try to avoid third party libraries as much as possible because each library is adding one more dependency on your plan.
    • Have an idea/capabilities about all the known technologies at high level. Dig deep only when required.
    • Think how architecture is going to be coded, tested, deployed and maintained before finalizing. At any point a developer, tester, infrastructure or support guy may come and ask how to do something in detail.
    • Learn buzz words / technical jargon to talk to different people.
    • Communicate to different level of people in different levels of details. To a client/stakeholder a holistic approach, to business don't use technical words, to managers only about deliverables and developers only in terms of programs.
  • Project management
    • Follow the below principle in Agile
      • Get it done - Demo
      • Get it right - Put into QA
      • Get it optimized - Production and maintenance.
    • Do not plan more than one sprint.
    • Create a new branch in source control start parallel development only when its really necessary.
    • Setup a CI & CD at any cost. Manual build and installation is old story.
      • If there is no test cases, do not push to production via CD.
    • Try to get code freeze at least 1 day during the build & release days.
    • Let the developers fix the hacks during the code freeze. But do not let them check in to main branch on which the build activities are going on.
    • When every project is starting customer will have a fixed goal. Its us who should throw new ideas,improvements towards them and keep continuing the project.
    • Make sure those ideas are business related and towards cost cutting for client to improve their profit. When client's profit increases our profit will also increase.
  • As a team member
    • Ask others to review your code and accept the good parts. Even ask juniors to review your code.
    • Do not just say its not working to your technical lead without a proper description or screenshot of exception or some links saying its defect. They will think that you don't know, didn't do debugging and google.
    • If you are taking a hack or shortcut, add the details with web links as comment in source code. So that future developers will not blame you. Do not keep it in mails, because the new members into your team will not get the mails.
    • Always give suggestions to business analysts requirement documents, proposed user interfaces. Most of the time they may not be knows what are the capabilities of technology.
    • Try to be truthful to testing team. When they come up with inconsistent help them to reproduce by understanding the code.
  • Team management
    • Always have one meeting in the morning and let the team explain what went yesterday and what is the plan for today.
    • Try to reduce the time required for your team to send reports. Get the details from task/project/work item management systems such as TFS.
    • Always look at the code your team is producing. To your superiors its your code.
    • Keep quick access to release dates, number of features and defects total and pending. if you can remember some showstopper/high priority defect ids, you will be a star.
    • Do not let project depend on one person. The show must go on at any cost.
    • Give ownership of tracks/components to single person or teams for fixed time say 6 months. Rotate the members to different teams in every 6 months. But never replace everyone in track in single shot.
  • Quality in software engineering
    • If you are clicking everyday as part of testing app, try to bring automation or look for next company.
  • Enterprise Application Development
    • Most normal things won't work in enterprise. Many things done there doesn't have any common sense. But have to do to keep the project moving.
    • It is very difficult to bring a change in enterprise.
  • Self learning and carrier improvements
    • Read others code.
    • Debug for others. 
      • There are many who can type code. But very less who can debug code.
    • Try to look into third party libraries. If its unmanaged, it will be difficult but in all the other cases its possible to view the source code of third party libraries. Obfuscation makes it little difficult though.
    • Learn one new language every year
    • Read at least one technology book every year.
    • Improve searching/googling skills. A best programmer needs to be a best googler.
    • Never waste your brain memory for language syntax. Google can give it in seconds from internet. Instead free brain to keep the capabilities and think freely.
    • Do not spend much time on learning short living frameworks such as Silverlight. Instead spend time on long living concepts such as http 2. 
    • Try to create and publish reusable libraries. There are very good library management infrastructures now a days such as nuget, npm etc...At least contribute to libraries. If there is no time to fix defects report the defects in the libraries.
    • Learn how things are working end to end. From business analysis, design, coding unit testing, functional testing, business testing, build systems, continuous deployment, application support and how to work with patches.
    • If you want to become a good business analyst you should be knowing what are the developers problems and how developers interpret the requirements document. For that best way is to work as developers. Similarly if you want to be good developers, you should know how QA tests your app. Again better way is to know is to work as QA. QA may not catch all the defects but its caught in application support. So to do better testing you should be knowing how the users use the system and best place is to work in support. To me an ideal career path is Application support->QA(manual + automation)->Development->Business Analyst. Join as support and climb the ladder, If there is no chance to climb in current company change the company.
    • When to leave company
      • Evaluate your activities in your company at least once year other than performance appraisal. If you feel you got only salary in return, leave the company.
      • If you feel you are the ultimate authority of something and everybody depends on you as you are the king, leave the company, because your growth is over there.

Monday, September 3, 2012

Learn programming interactively in online

Below are some sites which will help you to learn coding interactively by trying out as you learn!!! ie Its not just another video based which we need to watch for long.Rather these sites provide interactive console which allows you to write code and execute in the browser itself. Some of them also provides tracking capability so that you will be confident on what you learnt.

Javascript - http://www.codecademy.com/ (Really good for non-programmers)
Javascript - http://www.crunchzilla.com/code-maven (Fun learning for non-programmers)
Ruby - http://tryruby.org
Python - http://www.learnpython.org/
SQL - http://sqlzoo.net/
Lua - http://www.lua.org/cgi-bin/demo (Gives web based interactive console not step by step instructions)
.Net - http://mottishaked.com/training/dot-net-tutorial (This needs Visual Studio)

I really found these interesting as these do't need the long time environment setup to begin with or we will never get into sleep like video tutorials ;-) .Video tutorials are good when we just need to get awareness of the technology .But not good as interactive sites when it comes to becoming experts in the area.

Update 23OCT2012

Another page which lists more sites offers online learning materials both interactive and via videos
http://thenextweb.com/dd/2012/10/21/so-you-want-to-be-a-programmer-huh-heres-25-ways-to-learn-online/

Update 22NOV2012

http://www.ibrahimjabbari.com/component/k2/item/65-11-useful-online-coding-tools.html

Update 7Feb2015

http://devzum.com/2015/02/04/16-best-online-resources-to-learn-programming-easily/
http://mashable.com/2014/12/08/learn-code-resources/

Tuesday, May 22, 2012

For fresh programmers

This post is dedicated to fresh programmers. You can’t find anything related to a specific technology here. This contains some guidelines and links, a fresher should look at before he start his programming career. When I started my programming life there were no such chance to get these kind of guidelines as internet itself was too costly and there were not much blogs. When I said I started career it refers to my college days not the time when I joined my first company. I believe everybody agrees with me on my statement

“We start our programming career when we join college after selecting computer software development as primary subject”.

But in India I have seen companies taking employees or people joining software development companies without having the knowledge to write a for…loop.

You are the master of computer. Rule it

When a person starts with computer the first thing he learns is, it has 3 units .Input unit ,output unit and   CPU. Then he learns that computer has no intelligence or it don't have any capability to decide and do things of it's own. Whatever computer does is per the human instructions called computer program.

But most of the professionals will forget this after they became programmers. We could understand their change when they start complaining like "it works sometimes" or "I coded it well. I don't know why it is not working". Do you think the computer is injecting it's own code in to your code in order to take revenge on you? Absolutely not. So keep in mind that computer is a silly slave which works as per our instructions and you are the master.

Computer understands only binary instructions ie assembly language

You may using Visual Studio 2010 /2011, Eclipse, XCode or JBuilder for creating your apps. If you are using LightSwitch you may not have written single line of code to produce a business app. But remember what ever program you created, is going to execute using assembly instruction such as Mov A,B Add A, Push, Pop etc... If you don't have this basic idea about how a computer really process your program it would be really difficult to survive in the field of debugging and performance turning. Also you should have an understanding about how your managed frameworks such as .Net or Java convert the intermediate code to machine code to be executed by the machine.

Attend trainings & train others constantly

Like all the other professions software development too changes its way of doing .Also it changes it's tools and targets. But in programming the rate of change is really fast and if you need to stay with that you should always open to learning. If you think that I studied everything from college and can say bye to learning, please don't enter to the software development industry.

Are you confused and thinks that I selected a wrong path? Before answering it let's take the field of automotive. Centuries back, there were steam engines .The engineers at that time had to deal with steam engine's internals. Later the petroleum based engines came and they all had to learn the technology of petrol and diesel engines. Now we are in the age of electronically controlled hybrid engines and battery based vehicles. If you look at the tools, the manual screw driver is replaced by electronic screw driver.Also the targets, earlier there were only cars now we have hundreds of types and models of vehicles.

Don t' you think that, this is same as software development except the rate of change. We had big room full of machines first. Then it came to desktops,laptops and now to tablets and mobiles.In other industries it will take decades for a change but in software development its couple of years .Another field which we can compare with programming is the medical where doctors had to learn about new diseases and diagnostics tools every year.

so never miss a chance to attend a training or train others. At-least attend online training. If you are not a good speaker and afraid of talking in front of a big crowd start training your team which is comparably small. When you train somebody you will at-least learn 2-3 new things which you may had missed earlier because each individual thinks and asks differently.

Also read the books .Don't depend only on online media. Books give you vertical in-depth knowledge about the subject where internet blogs and search can only give you horizontal knowledge.

Be a blogger

Now a days without google developers cannot proceed further. In one way its true and should be like that because why should we memorize all the APIs of different languages which are going to be replaced by another set in next 5-6 years. Being in this context we need to think about one thing.

Where from the contents in google search comes from? Is Google creating contents by employing typists? No.Its due to the other fellow developers and their kindness to share their knowledge through blogs and tutorials. Are they just simply sitting and thinking about some scenarios and blogging the same ? 90% are not. They just share their day to day experience with programming and we are making use of it. If they had thought of completing their works and enjoy rest of the time we can never enjoy our life. Isn't it?

Same way think about new developers coming into our way. Do we need to make their life harder? If not please start blogging. Or post articles and tutorials. Don't say that I don't have topics. If you work 40 Hrs per week you might have come across at-least one situation which will help others in future. Write about it. Initially your language may not be good. But over time you will became a good writer. If you are looking to monetize your writings time just put google ads in your blog.

Read, debug and make use of other's code

One of my colleague always want's to code himself. When he wanted to try AI he started writing his on AI program using if...else which acts like any other publicly available AI chat programs. It's good that he wants to write himself which will help him to learn. But whether he really need to write himself where AI chat programs are available in open source such as AliceBot ? According to me as a smart programmer we should make use of other's experience.

The main advantage of using other's code is, they might have faced so many hard situations and resolved the same.Why should we face the same situations again? Another advantage is we could learn better ways of programming by looking at other's code or we can mix their coding style with ours to create a better one.So keep reading, reviewing and understand by debugging other's code

But be careful. Before using public code, read and understand carefully. Sometimes they may be less efficient than you. Also after adopting their code, don't say "Oh its not my mistake, it is the bug in their code".Keep in mind, once you adopt, that's your code.

Some sites you should really look into

These are some sites which I feel a developer regardless of your experience should read.
http://samizdat.mines.edu/howto/HowToBeAProgrammer.html
SOLID Principles

Site for non-software people to learn programming
Learn coding - http://www.codecademy.com/

Books to understand basics
Code By Charles Petzold - Explains the evolution or computer and programming from basic electronics to assembly language & high level language.
Head first Object Oriented Analysis and Design

Tuesday, February 21, 2012

Indian campus way of problem solving

Couple of weeks back, I had to go an engineering college campus nearby, related to recruitment in to our company.  It is a self financed private college running very well with good discipline and all. But I could see the art works of students in the desks like a government college:-). According to me the desks or tables are the initial area where students can show their drawing skills.

As usual I could see students from all the branches coming to attend the interview for Software Development job.There were 5 rounds to be passed to get the job.First the aptitude test,next round is a group discussion. Third a technical / programming test followed by a technical interview.Finally a management interview ie HR interview (Human Resource).

My part mainly started with the technical test and ended with the technical interview. When I corrected the papers, I could see that the theory questions are very well answered such as "What is the difference between while and do while loops ?","Characteristics of OOPS ?" etc.. But when the programming question is answered, I could see a struggle for students especially the non-computer science or students who are not interested in programming. Most of the students in non-computer science stream didn't attend the programming questions.Even if somebody attempted they just wrote the initial 2 lines of a C program which they might have seen in their 3rd semester.


#include <stdio.h>
void main()
{
}

The characteristics of computer science and non computer science students is not our interest .I am just about to say the problem solving attitude of 2 candidates who attended that interview process.The answers took my attentions are

Qn : What is the result of below code ? If its a compilation issue how to correct?

double number=546.4;
int newNumber=number;

Ans : Compilation error .New code
double number=546.4
double newNumber=number

Simple isn't it? No casting .No conversion etc...

Qn : Display the below using for loop ?
$1$$2$$$3$$$$4$$$$$5
Ans:
for (int i=0;i<1;i++)
 Console.WriteLine ("$1$$2$$$3$$$$4$$$$$5");

There were so many answers which accepts an input number and displays dollars using loop.Even we expected the same answer.But if we closely look at the question there is nothing specified about getting an input number and display the string in the given pattern. Smart answer .Isn't it? Not many people can think in this way. This was from a mechanical student but unfortunately we were not able to get him due to next rounds :(