(Comic) Defensive Programming

Link to Comic

(Comic) The Standup Cycle -- in Agile Teams

If you have daily stand ups, then you should be familiar with this standup ritual that occurs few times each year.

Link to comic on Pixton

(Comic) Programming Language or the Algorithm -- The choices we sometimes make

Link to Comic

This comic was inspired by the Levenshtein algorithm I was reading about yesterday. 

Sometimes we love the tools so much, that we forget the technology. Try and solve problems too. Its fun.

(Comic) Comfortable in Red

A second attempt at making a comic on Pixton. People on teams need to ensure they practice what they preach, and not get comfortable with status-quo.

Link to Comic

(Comic) Collaboration vs Coding -- A developer's challenge

I decided to try out Pixton to create some comics. Here is my first attempt:

LINK TO COMIC

Collaboration vs Coding

The Way To A New Project --- Becoming Effective

You move to a new project. Its exciting. It holds promise of something awesome (usually). You are ready to dive. You want to learn things fast. You want to contribute. You want to become effective. You want to be welcomed. And then maybe, become invaluable.

There are some tips I have learnt on how to navigate new projects effectively. I would look forward to hearing what you have to say about yours. And, I suspect there will be more.

1. The more experience you get on multiple tools and technologies, the easier it is to move to newer projects with newer tech stacks. 
2. The more you master one programming language, the more difficult you find adopting another language. Especially if you are a perfectionist.
3. The more you expose yourself to various languages, the better you program in all previous languages.
4. The quicker you understand the domain of the project, the quicker you understand the code of your project (unless people in your team like naming everything as “data” or “temp” or “value” or “count”, in which case you are doomed, and you should quit).
5. Understand the database of your project. The database brings insights into relationships between entities. These relationships will remain permanent for a very long time, while the code on top that manipulates the data, will keep getting refactored. Once you get a handle on the data, the code becomes much easier to understand. 
6. Pair with QAs. Perform testing. You will understand the domain, and the interdependencies very fast.
7. Ask questions, write notes, and volunteer to take sessions on project topics / technologies. Nothing teaches us faster, than the pressure to not look foolish. 
8. Try and understand the reasoning behind why features are being built, because 60% of the features in all software products are built for the same purpose — each using a different technology or tool. For instance, every corporate website has Search, Page Analytics, Splunk Style Logging, Meta-Tagging for SEO, JS/CSS optimizations for performance, Device & Browser Detection and Cookie Manipulations for Personalization, Responsive design, REST based integration, SSL, etc.  
9. Follow a user journey in code — to understand all the layers involved, and how they interact. A decent codebase, usually has a few patterns that are repetitively used. 
10. Use a good IDE for navigating code. They will help you understand code paths, callers, implementors, etc very quickly. I use IntelliJ (Cmd+Alt+F7), and Sublime. 
11. Read the unit test to understand the class. Of course, I work at ThoughtWorks, and therefore have the luxury of seeing self documenting unit tests. And this means, I am indebted to ensure that readers of my code also get a good unit test.
12. Hunt out for project documentation — especially those which pertain to large scale features, architecture, etc — as they summarize information quite well.
13. Sign up for devops tasks. They will help you understand the interdependencies between systems very quickly.
14. Find out who's who on the project (customer side), so that you know whom to reach out to, for what insight. 
15. Have patience. It takes a minimum of 3 months to “feel” effective. And then another 3 to be “one-with-the-project”.

I know. It’s not a shortcut. It’s a path.

Difference between sorted, sortWith and sortBy in Scala

Scala collections provide you three options for sorting: sorted( ), sortWith( ) and sortBy( ). Here is a simplified explanation:

sorted
Will sort the list using the natural ordering (based on the implicit Ordering passed)

sortBy (an attribute)
Sort by a given attribute using the attribute's type.
e.g. given a list of Person objects, if you want to sort them in ascending order of their age (which is an Int), you could simply say: personList.sortBy(_.age)

sortWith (a function)
Takes a comparator function. Useful when you want to specify a custom sorting logic. 
e.g. if you want to sort by age descending, you could write this as: 

personList.sortWith{(leftE,rightE) => 
     leftE.age > rightE.age
}

Or, more simply: personList.sortWith(_.age > _.age)

Checkout this gist for a full example: 
https://gist.github.com/gsluthra/80555ed4af24bea244b5