5 annoying Linkedin Usability Bugs! Does Linkedin care to fix?

This post was originally posted in Linkedin Publishing platform.

In this post I am going to write about some LinkedIn bugs that are annoying me for a long time or don't stand good from the usability standpoint. So here we go with the list.

Numbering doesn't work

Irritation Quotient: 5/10

Justification: As an upcoming blogger / writer it really pisses me off when I see that the contents that I typed in are not exactly in the same format as I typed. Why? Because presentation is the first thing that people notice. A blog post is only read if it appears beautiful / presentable (at least for upcoming bloggers/writers). OK. So what's the actual issue. Whenever I write few points and number them in the answers (Let's say 1,2,3,...) to group discussions, those numbers get displayed as 1, 1, 1, 1, 1, 1, 1... Oh my goodness! I am certainly better than this at numbering.

Status Update takes a long time (for the first time when i sign)

Irritation Quotient: 3/10

Justification: Whenever I do a status update, it takes a while before it shows up on the timeline. What's worse, there is no indication that I have updated something even after typing and pressing the Share button. But when I press Share the second time, it gives a message "The same message can't be posted twice"

Biggest hindrances to being agile

I often wonder how projects fail to be agile enough even though the team consists of talented team members.  So today I am planning to summarize few points that are the biggest hindrances to being agile in a team based environment.

1.  Laziness / Procrastination

I think this is by far the number one hindrance to being agile.  This habit by individuals will result in a gap that widens with each work that is being delayed.  Let me explain this a bit better.  If you are part of a QA team, your responsibilities will primarily include testing of your module perfectly.  Obviously everyone will do that.  But automating the current testing will act as a regression suite for your future needs.  How many of you would do that if automation is not mandated in your process?  The answer is not all.  

So the laziness / Procrastination sets in and the gap widens with each delayed item.  So unless automation is mandated, it will not be implemented by everyone.  So the Agile Definition of Done should include all these nitty and gritty details that makes the entire process more agile.

2.  Lack of understanding

Not everyone is comfortable with Agile concepts and the lack of understanding of Agile has a direct impact on the team performance.  No Agile is almost always better than bad Agile.  For example, trying to be Agile without giving importance

Top 5 blog posts of 2013 - AgileDevTest

Just a little recap, It's been nearly 11 months since I started the AgileDevTest Blog.  This knowledge sharing and learning journey has been wonderful for me and hope my posts are informative to you.  In case you are not satisfied with any of the blog posts, as always, please feel free to post your feedback either as a blog comment or you can also contact me directly in my G+ account.  

As we are approaching the end of 2013, I just wanted to share the top 2013 blog posts of AgileDevTest Blog.  So here we go with the list

5.  Free Ebook for Beginner Programmers - Programmer's Motivation for Beginners

This blog post is about my free Ebook "Programmer's Motivation for Beginners".  More about this on the given link.  This post received good welcome and is #5 in AgileDevTest blog 2013.

4.  Attitudes of a Great Software Developer

This was my very first blog post in my own words.  I had a sense of feeling that Developers needed to have certain attitude if they had to classify as Developers, this blog post throws some light on those thoughts.  This is one of my personal best and it's #4 in AgileDevTest blog 2013.

Agile, Agile, Agile. What is so different about Agile for Developers and Testers?

The word Agile has taken the software world by storm.  Agile has grown well past it's hype cycle.  People have got increasing awareness about Agile, however doubts still remain in several minds especially developers and testers.  So what is so different about Agile and how does it matter if you are a developer or a tester?

Fast Paced Environment

Typically Agile Environments are fast paced.  It doesn't mean that there will be no breathing space.  No.  That is not the case.  In good Agile environments, the outputs are faster.  It takes lesser time to deliver same features in a good Agile environment.

More focused results

The problem with many focus is that they try to do too many things at once.  And many a times, multitasking is counter productive.  That is both true for an individual or a project.  So Agile puts more emphasis on providing proper attention to the things that really matter.

Focus towards customer rather than technical easiness

Given a choice between easy for the customer vs easy for us, we almost take the latter option.  And that makes sense sometimes, but not always.  However in Agile Projects, customers are kings and if there is something that will be easier for the customer, we will do that even though it means that it might not be technically easy.  There are of course technically infeasible aspects but that is a different point altogether.

What Software Developers can learn from Sachin Tendulkar's marathon career?

A great career is about to end.  One filled with many many runs that even the best can only dream of.  Yes, we are talking about the one and only Sachin Tendulkar.  As he is retiring, I just thought of how much I learned by just watching him.  That's when I realized why not pass that learning to others as well or at least highlight what we can learn from him. 

 

This post is specifically dedicated to software developers.  But this can be applied for anyone in any field.

 

So what are the things that software developers can learn from this great guy?  Here we go with the list.

 

 

 

 

Passion for the game

One thing that is pretty to hard to beat this guy at a young age or even now is his passion for the game of cricket.  He used to bat, bat and bat without getting tired at the nets day in and day out.  He loved the game so much that he lived it. 

Similarly developers should be passionate about developing great software.  It is the passion that keeps a man going and work never looks like work if you are passionate about it.

 

Natural Talent

14 Code Refactoring smells you can easily sense and What you can do about it?

This post is specifically intended to Project Managers although developers and testers can also get reasonable inputs from this post.  Generally projects tend to accumulate a lot of technical debt over time if refactoring is not applied and if good coding practices are not followed.  It is imperative that as a Project Manager you should understand this and deal with it effectively.  This is especially true in an Agile Project, where there is constant delivery of features and you would be surprised how quickly code quality can take a beating in if proper measures are not taken.  So what are the signs you can observe that your project’s code needs refactoring and what you can do about it?

·         Team is taking more time than expected to deliver features

o    This is probably the number one smell that a Project Manager can look out for in a project.  As a Project Manager you sense that a certain feature should not take so much time, yet it takes that time.  You talk to the team and they often give you a detailed explanation of how much change the feature needs to undergo and how it affects other features.  That is one of the sure smell that indicates that the code needs refactoring

·         Plenty of bug fixes after delivery

o    On one end, the code delivery is being delayed and at another end, there will be a lot of bugs too after delivery.  If you have observed this, then it is a sure sign that your project’s code needs refactoring.

·         Build Quality is on a decreasing trend

o    This is one of the excellent smells that surely indicate the need for refactoring.  If we try to build on bad code, the code quality will get reduced and this trend continues till we attempt to put a stop to it.  If you observe this as a Project Manager, then you need to put a stop to it.

Common excuses a Developer makes when a feature doesn't work [And how to avoid them in the future]

I always feel that Developers should have an attitude for development, which I have detailed in the blog post Attitudes of a Great Software Developer.  But generally when it comes to issues, a lot of developers make excuses.  As long they are genuine, it is not a matter of concern however if it is really an Excuse, then it is a cause for concern for the entire team.  I am guilty of a few of those myself however when I saw the big picture, I rectified those and understood why people make those excuses and how we can avoid them in the future.  I am detailing a few in my below post.

1.  It works fine in my machine

Come on guys, this is the number one excuse that developers give.  We often have a feeling that testers or the customers have a magical computer which injects bugs into our code.  But that is far from true.

The only way to avoid this excuse is to be aware of the environments that are used for development, testing and production.  By being aware of those, the first thing you would probably ask is, what sort of configuration/environment it is and get more details about the issue and check if it is really a valid bug.  Another way to avoid this is to have a Continuous Integration environment, where with each and every code check-in, code is compiled and deployed in some test machines.

Image courtesy: cheatcc.com