Saari Development

Ali Rizvi's Technical Blog as a Professional Software Development Engineer

Archive for the ‘software-development’ Category

My Advice To New Software Developers

leave a comment »

  • Don’t settle too early and don’t artificially constraint yourself. For instance:
    • Don’t say I am a Java or .NET developer and restrict yourself to only those platforms
    • Don’t stay in the same company for too long, some times you settle for 1 year of experience repeated 5 times rather than 5 years of real experience. You can always come back to a company if you like it better than the next one. In large companies you can move to a different group.
    • Don’t move too fast, take the time to learn from the smart people around you. If you are the smartest person there leave immediately.
  • Keep learning new and perspective changing technologies and not learn more of the same. For instance:
    • If you know a object oriented language (C++) learn functional language like Haskell
    • If you know a statically typed language (Java) learn a dynamically typed language like Ruby
    • Keep an eye on the trending technologies and briefly explore them to get a taste of them
  • Teach what you have learned to others, you have learned it if you can teach it

Written by imsaar

September 3, 2014 at 12:37 pm

Collaboration and Software Development (Part 1 of 2)

with one comment

I believe quality software development is a collaborative process and I personally consider myself a collaborative person (there could be some cognitive bias here)  I am happy to be working in an organization in which being Collaborative is a recognized as a core value.

The above assertion raises some questions:

What is collaboration?

Collaboration is the act of working together, caring about the common product and each other. Collaboration is often confused with cooperation which is different. I found the distinction cited here very well done:

Dillenbourg et al. (1995) make a distinction between cooperation and collaboration.

They define cooperative work as “... accomplished by the division of labor
among participants, as an activity where each person is responsible for a
portion of the problem solving...” They define collaboration as “…mutual
engagement of participants in a coordinated effort to solve the problem
together. They further note that work often is split also in
collaboration. But the difference is that in cooperation the task is split
(hierarchically) into independent subtasks, and in collaboration the
cognitive processes may be (heterarchically) divided into intertwined

Another concept that is similar and confusable is contribution. Which is doing your part towards the goal but not necessarily as part of a team or together.

What is the opposite of collaboration?

Sometimes helps to identify and understand the opposite of a concept to appreciate the concept itself. So what is the opposite of collaboration. Some would say Coercion but I think it is Competition.

I have seen it many times in my 10+ years of software development experience where individuals would get in a competitive mode due to internal reason like personality types or external reason like management’s scarcity mentality where people are stack ranked on basis of individual contributions.

How does competition looks like in a Software team?

  • My code is better than yours.  There should be a joint ownership of all of the code in team.
  • I don’t have time for your problem. If this is a team they should be working towards a common goal hence any problem is our problem.
  • Common use of hand waving help where you don’t really get engaged in the problem solving just try to give an idea to try to get back to “your” project/piece.
  • Rubber stamp code reviews
  • No passionate disagreement or challenging of individual assumption. This is passive competition or lack of care.
  • Criticism without owning the problem or offering a solution.

Read the rest of this entry »

Written by imsaar

December 28, 2010 at 6:40 pm

Book: Pragmatic Thinking and Learning

with 2 comments

The frisson never died. The excitement kept me turning one page after another. Andy Hunt’s Pragmatic Thinking and learning : Refactor Your Wetware is life changing and I highly recommend it to all Software Developers new and old.

Pragmatic Thinking and Learning (PTL) is full of ideas and insights. It is based on a lot of research and background reading. It would save you a lot of trouble of going through a lot of books and research to learn the same material which might not be written this well. I had already read some of the books mentioned in the book, some were on my candidate list and some I added to my candidate list based on citations from this book but this is a concise collection of all these tips and tricks you learn from all these books (some of them I will never read as they are research on neuroscience and nursing professionals).

What does Pragmatic Programmer and Pragmatic Thinking and Learning have in common besides practical advice, tons of insight and being my all time favorite books? Andy Hunt. Andy is awesome. Not only he writes well he is a very articulate speaker. In fact the way I got introduced to this book while it was being written was a talk he gave at my company. This book is so much more than that talk I loved.

I will write more about the practical tips as I act on them in the future in this blog or on my twitter but for now I just wanted to give a shout out for this fantastic book.

If you want to buy it from my favorite book seller online here is the link.

Written by imsaar

April 10, 2009 at 5:09 pm

Software Development: Correctness, Completeness, Performance, In That Order

leave a comment »

Software development is the act of converting thoughts into actions. In other words goal of software development is to convert requirements into code but this can’t be done in one step and in a single iteration.

Each iteration in the software process you need to get a piece of requirement convert it into design, write a test, add new code and potentially refactor existing code to implement it.

For every piece in each iteration you want to follow the ordered sequence of correctness, completeness and performance. In other words, get it right, get it working, get it fast.

When understanding the requirement you want to make sure you are getting the right requirement basically understand what customers want not what they think they want. Often in requirement gathering phase the customer is biased to what they are used to or how they want something rather than letting you know the input and output they desire from a feature. Your job is to get to the bottom of it by asking good questions.

In the context of requirements completeness means that you not only understand the input and output but the entire context to implement the feature correctly. Once you understand what and in what context only then you turn your attention to performance requirements (if any) as discussion of performance earlier might not be in context and well understood where the customer is coming from. All these discussion do not have to happen at the same time but in should happen in that order.

I think I have already explained the hardest part in the whole iteration. Requirements is often where we get it wrong and the hardest/most-expensive one to correct after the fact.

When it comes to writing code you also follow this sequence, make sure you are implementing what you intend on implementing by writing unit tests first. The act of trying to write test first often force you to think about what you are about to do. You repeat this process until you have met all the requirements for the feature (completeness) and only then you measure performance and do any performance tuning if necessary. Software developers are not only often guilty of the thought crime of premature optimization but actually commit this crime if not stopped in time.

Do you think my thoughts are incorrect, incomplete and would not scale? Please send me a thought patch in the comments.

Written by imsaar

February 19, 2009 at 6:18 am