As I am growing in a leadership career, I am finding that I am reading and writing more business documents than code.
I studied for years on how to write code before writing it professionally. I never did that for business writing. Therefore, I decided that i should learn that. I picked a couple high rated udemy classes to get me going. The goal was to identify 5 things I can immediately apply to all important documents I or my teams write.
This article is about sharing those learnings from my perspective. I will talk about 5 key things that I am taking away from my quick education about business writing.
#1: Be clear:
Use clear english. Use the right words in the right way to make a clear point. It means using clear, small words that do the job.
Have a clear understanding of why you are writing. Why should anyone care? What do you want from your audience?
Use small sentences. It’s hard to maintain the flow in longer sentences and they are often unclear. They fail to communicate clearly.
Use Active voice i.e. SubjectpredicateObject. Active voices are direct, more influential. They keep the reader engaged.
Use simple words. Don’t use complicated words when a simple one does the job. Don’t try to be smart. Try to make your reader feel smart.
#2: Structure is very important:
Think about how you will structure your data. What is the flow of your document? Is the most important information hidden or highlighted? Chances are there is too much information in your document causing ambiguity or reducing interest. Is written communication the best way to handle this topic?
#3: Have Empathy:
You are writing because you want your readers to do something. Potentially differently. In other words, you are writing to influence or make a point. It’s best to always assume
Your readers are busy so you have to make it easy for your readers to read your work.
It should be inclusive, avoid jargons if you have doubt that they won’t understand (consider audience, think if they are from diverse background, new to the org etc)
Have the most important information first (Objective, Action, TL;DR), followed by supporting facts and reasoning.
Clearly mention the intent if you are requesting someone to do something by a certain time.
#4: Polish your work:
The higher the stakes, the more time it needs polishing. It is important. No one likes to read just a blurb of text. Especially not busy people.
#5: Review, Review and Review:
Review that your document hits the point you are trying to make.
Review for grammar and spelling mistakes (I make them the most)
Review the audience set again before sending and check for inclusion/empathy
If stakes are high, consider a peer review
Let it bake. Put your document aside for a while, revisit it and you will find that you may have a new perspective.
I found these ~6 hours of investment incredibly helpful. Practice makes skill better, so I plan to practice by writing articles such as this. If you typically write to advocate some action. I strongly recommend some education behind business writing skills
Many companies are in the process of doing their year end reviews this time of the year. This means that a lot of people are thinking about their career, where they stand and how to move ahead and make progress.
I am a firm believer that we own our career ourselves. This is also the advice I usually give to anyone who asks me “how can I grow?”. One of these times my team member bravely asked – What exactly does it mean to own your career? While I understood what it meant for me (I think) I realized it’s genuine and probably a very valid question. How do we define this? What does it translate to?
I will make an attempt to describe it in my way what does it mean: “You own your career”
What is a career?
In order to talk about career, I need to talk about the big picture. Without that we are just travelling with no destination. In my opinion we all should have a big picture, a destination in mind on where we want to reach. It does not always need to be achieving high ranks (although there is nothing wrong with that if that’s your goal e.g. to be a CEO). It should be what’s meaningful for you. A few examples could be, being a visible voice in your industry, being financially independent to retire early, a significant contribution in your field or org. It should be something that is organically yours and does not change from company to company.
Ultimately the professional journey towards your big picture is career.
Lot of us, spend most awake hours everyday working and making a career.
What is ownership?
There are so many amazing articles and books about ownership that describe it in so much more elegant manner. In simple words, it means taking charge. Taking charge to change or maintain something is ownership and when we act like owners, we empower ourselves to make decisions that impact that ownership for the better.
Breakdown: You own your career.
Most companies I have worked with, there has been a career ladder. A level 1… to level n and a tool that drives what are the expectations and needs from a certain level. Performance reviews are benchmarked against those levels and as the company grows they get to tweak accordingly.
The most common story I hear is, “I want to go to the next level and I need help from my manager to get there”. It is very important that your manager knows about your plans and intent to move to the next level. This is actually one of the steps in owning your career. What’s critically even more important, is that you and your boss know about your big picture goal. I believe most people miss this latter part.
It’s important to understand that current level and next level are mere tools to your big picture. As I said earlier, ideally the big picture wouldn’t change from company to company. It is likely that climbing that ladder is necessary to achieve that goal (it may help you with skills, relationships, money etc needed for the big picture). Being aware of the big picture helps you and your manager to see other paths to get to the bigger goal.
Let’s continue on what would be a good example of owning a career, where the immediate next step would be to go from level current level to next level.
Establish a baseline
Get an idea of where you stand today (are you performing above, at, or below expectations of your current level x) after discussing it with your manager.
Understand the why
Why do you stand where you stand? It is easy to interpret as, understand your weakness, but also understand your strengths. if I had to pick one, I would advise focus on your strengths1
Understand the level next level
Does your company have a written guide on what are the expectations on the next level, what are skills needed?
If your company does not have a written guide, ask your manager to provide that guide for you. Ask your manager to review job descriptions of the next level and help you figure it out. (It might also be smart to go work for a company that has thought about growing their employees and have invested in written guidelines)
If so, have you read them?
It is probably more generic than you like, have you thought how does that apply to you?
Have you asked clarifying questions to your manager?
Who in your org is working effectively at that next level?
Understand few people in your org are working really well at that level?
Try to understand what are the things they are doing that makes them effective.
Workout a plan
Based on all above understanding, plan on how you will get to the next level.
Understand what skills you need to perfect.
Understand what relationships you need to build.
Understand what short term and long term projects/problems your organization wants to solve. Solving these projects will act as a tremendous catalyst for your growth.
How can you help solve that project/problem by your skills and relationships?
Team up with your manager
Share and align your plan with your manager.
Confirm that the projects/problems you have identified are worth going after.
Confirm the skills/relationship you need to build.
Adjust the plan after collaborating with your manager (make the most of your manager’s extra visibility in the org)
Utilize 1-1 to effectively communicate progress and gather input.
Adjust the plan as business pivots
Your company will grow over time (new managers, new business, change in priorities, pandemics) and everytime that happens, understand how it affects your plan and discuss with your manager.
Repeat until you reach the next milestone.
You may have noticed that the ownership of most of the work I described here falls on the person seeking to go to the next level. Your manager can and should always partner with you to tune your plan to have the most chance of success, but your manager cannot build the relationship and/or skills you need to gain to perform well at that next level.
Your manager will act as a facilitator, enabler and advocator for you, but not a doer for you.
Your manager also has a lot of responsibilities that will indirectly help you achieve your next steps.
Provide a written guideline of what are expectations at each level.
Provide clear feedback/feedforward on where you stand today and how you are progressing.
Help in finding the specificity that you need in your growth plan.
Create enablement for you so you can learn new skills or master what you have, build relationships.
Hold you accountable to your goals.
Think wider than their own org, i.e help you grow, even if it means you won’t report to them anymore. Identify new opportunities
Understand your unique style and find you mentors as necessary.
Build a team that supports each other’s growth.
In simple terms, if you have taken the time to think about the big picture, break it down to smaller accomplishments and next steps, worked towards understanding what your business values, partnered with your manager on a plan and are working towards that plan, then you my friend have owned your career.
Thank you Praveena Johnson, Ailene Kim, Joe Chung, Binal Parikh for making this article better.
Hi friends, I would like to share something that I recently had to figure out as I thought about my succession planning. As a leader of group of people, I was in a lookout of who can potentially be the next leader in the team. After lot of reading of leadership pipeline and blogs, articles and combining it with own experience, I boiled it down to three pillars. I would like to share them with you, in case you are finding leaders in your team 🙂
There are three things that I call pillars of identifying a potential leader. I believe its really important for you to observe and measure in these three categories to identify next set of potential leaders in the team. The goal I had was to identify potential leaders and have conversations with them about potential pursuit of leadership, after all leadership is a choice.
This venn diagram will give hints!
Credibility: I really think credibility is really important for someone to be considered as potential leader. What is credibility? – Its a quality of being trusted and believed in. If you have someone who you consider can be trusted and believed in probably any work and they will give their best effort to produce great result. They are credible people. The interesting part is trust, it comes when one demonstrates that ability over and over. So really people who had repeatedly delivered high quality work regardless of the problem space, are credible people in your team. After all, influence is really important for a successful leader, and it comes from being credible
Self-Motivation: People who don’t wait to be told what to do are self motivated people. They don’t settle. They always look for ways to change, improve and are hungry for tiniest bit of improvements. They find ways to accommodate those improvement in difficult times. If you want to give team a leader, that will continuously strive for improvements self-motivation is a definitely required. In my opinion, the leader of team can motivate the team, simply by exhibiting self-motivation.
Leadership: This sounds odd, I know. You may be thinking that why I am putting leadership as one of the pillars in my quest to find potential leaders? In your attempt to find your team the next leader, you need someone who have exhibited some qualities of leadership. There is so much to learn and practice in leadership (I personally still have ways to go) but anyone can demonstrate leadership traits, example finding real joy in delivering value via others, empowering others, coaching, active listening etc. Seasoned leaders sometime fail to demonstrate the above mentioned skills, so if you have someone who have demonstrated signs of above, there may be more potential. Dig in.
So I talk about these three pillars, but the way I think about is, the next most potential ideal leader would be someone who exhibits all the three things consistently.
Let’s say you you found people in your team that fit in the star in the venn diagram, now what?
The next step would be to have a conversation! Have an open conversation with them about why do you see them as potential next leader, what would it be like and are they really interested in doing something like this. So many leaders assume that everyone wants to be a leader, I know so many people that find pure joy in just being individual contributor and thats totally ok! so just because you thought of them as leaders, doesn’t mean they did, so talk to them and have an open career conversations.
What if you didn’t find someone, or found someone close enough but exactly there. It’s still our jobs to have a conversation and see where they want to go, what they want to do and if they want to be a leader, what are the next steps to bridge the gap! Have a career conversation, have them prepare a plan for bridging the skills. At minimum, they will find it really encouraging that you saw potential in them and are willing to work with them on their strengths and improvements
Cheers, hope this helps you in your quest of finding new leaders in your org.
Being a software developer is not easy. When I say it’s not easy, I do not only mean its technically challenging, but its also emotionally challenging.
We as a developer can get attached to our code. We write it while our mind thought of creative ways to solve complex problems. The solutions we have are like our brainchild. However we work in a world that is constantly changing. Change happens around us and its inevitable. You can do scrum, mocks, freeze the product specification but a change will always happen and it can happen to an extent that the code you have written for a problem would not be applicable anymore. As far as that product is concerned, you may as well trash that code.
Despite of all that, I am here to tell you that its okay. It’s okay to throw your code and write it again. Yes it requires time and it’s not always justified but every creative challenge you have solved while writing that code has made you a better developer already. It may not do the product any good anymore, but it has already done good to you.
Every time you discover a new or a better way to do something it makes the previous method obsolete. Developers would often create something and keep throwing away/updating their code until they are satisfied with its performance, neatness and efficiency. The earlier in your developing career you learn, that its okay to throw the code and write it again, the more happy you will be working as a developer.
I have had plenty of encounters where I had to throw away the code and write it again, but every time you come back to a problem after a while, you have a fresh point of view and possibly a different approach, which can be efficient and better than the previous approach. Even if its not efficient than the previous one, its definitely neat and organized than previous one. It’s because you have already solved the problem once.
Therefore my friends, if you find yourself in a situation where you probably have to trash your code – archive it, and if you happen to write it again, compare the archive with the newly written code. You will probably find that you have gotten better.
Equal operator comparison
null == null
null == undefined
null == 0
null == ” (empty string)
null == NaN
null == ‘2’
null == 2
undefined == null
undefined == undefined
undefined == 0
undefined == ” (empty string)
undefined == NaN
undefined == ‘2’
undefined == 2
0 == null
0 == undefined
0 == 0
0 == ” (empty string)
0 == NaN
0 == ‘2’
0 == 2
” (empty string) == null
” (empty string) == undefined
” (empty string) == 0
” (empty string) == ” (empty string)
” (empty string) == NaN
” (empty string) == ‘2’
” (empty string) == 2
NaN == null
NaN == undefined
NaN == 0
NaN == ” (empty string)
NaN == NaN
NaN == ‘2’
NaN == 2
‘2’ == null
‘2’ == undefined
‘2’ == 0
‘2’ == ” (empty string)
‘2’ == NaN
‘2’ == ‘2’
‘2’ == 2
2 == null
2 == undefined
2 == 0
2 == ” (empty string)
2 == NaN
2 == ‘2’
2 == 2
null === null
null === undefined
null === 0
null === ” (empty string)
null === NaN
null === ‘2’
null === 2
undefined === null
undefined === undefined
undefined === 0
undefined === ” (empty string)
undefined === NaN
undefined === ‘2’
undefined === 2
0 === null
0 === undefined
0 === 0
0 === ” (empty string)
0 === NaN
0 === ‘2’
0 === 2
” (empty string) === null
” (empty string) === undefined
” (empty string) === 0
” (empty string) === ” (empty string)
” (empty string) === NaN
” (empty string) === ‘2’
” (empty string) === 2
NaN === null
NaN === undefined
NaN === 0
NaN === ” (empty string)
NaN === NaN
NaN === ‘2’
NaN === 2
‘2’ === null
‘2’ === undefined
‘2’ === 0
‘2’ === ” (empty string)
‘2’ === NaN
‘2’ === ‘2’
‘2’ === 2
2 === null
2 === undefined
2 === 0
2 === ” (empty string)
2 === NaN
2 === ‘2’
2 === 2
Or (||) operator comparison
null || null
null || undefined
null || 0
null || ” (empty string)
” (empty string)
null || NaN
null || ‘2’
null || 2
undefined || null
undefined || undefined
undefined || 0
undefined || ” (empty string)
” (empty string)
undefined || NaN
undefined || ‘2’
undefined || 2
0 || null
0 || undefined
0 || 0
0 || ” (empty string)
” (empty string)
0 || NaN
0 || ‘2’
0 || 2
” (empty string) || null
” (empty string) || undefined
” (empty string) || 0
” (empty string) || ” (empty string)
” (empty string)
” (empty string) || NaN
” (empty string) || ‘2’
” (empty string) || 2
NaN || null
NaN || undefined
NaN || 0
NaN || ” (empty string)
” (empty string)
NaN || NaN
NaN || ‘2’
NaN || 2
‘2’ || null
‘2’ || undefined
‘2’ || 0
‘2’ || ” (empty string)
‘2’ || NaN
‘2’ || ‘2’
‘2’ || 2
2 || null
2 || undefined
2 || 0
2 || ” (empty string)
2 || NaN
2 || ‘2’
2 || 2
This works like standard || or operator, if the value of the first comparator does not equals to true it will select the other value. See section truthy value for which values return false when asked for boolean value.
if ( null )
if ( undefined )
if ( 0 )
if ( ” (empty string) )
if ( NaN )
if ( ‘2’ )
if ( 2 )
Let me know in comments..
PS: I originally created this post in jsfiddle here (http://jsfiddle.net/bsurela/13gdvom5/)
This post is just dedicated to check out http://bhavinsurela.com/color-generator/, a simple random color generation that i created. This is no rocket science but its fun to drag and drop colors around each other and to see them create different colors.
It works best in Chrome and uses drag and drop of HTML5 and also uses local storage. This is just a gig and some couple of hours of work, but I still hope it will be used somewhere.
Happy new year folks. I hope you had a fantastic year and plan to have a great 2015.
I am going to start 2015 with a simple naive trick. I am sure there are other good ways and things out in the wild to achieve similar results.
I was visiting a site for holiday shopping and I notice tons and tons of console logs. I assumed that the site was in debugging mode and had lot of console prints. It got me thinking that what would be the easiest way to get rid of those console logs in production while still keep them in debugging/developing mode. Of course assuming that they have no prior built-in switches for that.
I opened up my fiddle and here is what I came with, It works well and pretty easy to use. Its a simple logger. It uses domain name array which is the array of all the domains in which the console.log should be hidden (example, production domain). It has a force switch which allows you to still print logs in production (in case you are working like me where your end users are in the same room). This is a bare-bone structure to give you the idea – it can obviously be tweaked according to one’s need.
Here is the embedded fiddle
With this, all the console log disappear from production while still appear in everyones local.
Hope this helps someone.
Every machine evolves over time and gets to a point where it needs to be replaced or enhanced to fit new and changing needs. There are very less things that are sustainable to change. Software Applications are no different.
As time progresses, as new technology arrives, new ways of doing things become the “norm”, things that were developed years ago start to age, appear old and tacky and calls for migration to the new system.
However migration is not always easy, not always necessary. Biting the bullet of migration is also a challenging task and there are certain things that need to be carefully determined before we jump in migration.
Still reading? Lets take a look at what things we should consider before jumping to migration.
Life of a software as it is
As we just discussed, software application have an expiry date and though they are kind of working and get some work done, they tend to be replaced with a newer better version of it, specially when new technology comes often. Applications that are end user exposed example, website, mobile and desktop apps tend to expire more early then those backend applications, just because as new user experience techniques comes in to market, the old and not upgraded systems look outdated and are prone to loose business and are not appealing to the user.
So how do we determine if an application is aged and needs to be replaced?
Here are the hints
Team spends more time patching things rather than building on it
The underlying technology is so old, that we have limited support for it.
User complains / User experience becomes unpleasant
The application does things inefficiently than the competitor just because of its underlying technology.
Obviously this is not a complete list but should give us the idea that we should start thinking about migrating our system to a better one.
Development to Usability Ratio
While all of the above still holds true, we should not rush to migration. One of they key point is development to usability ratio. The complexity of migration of an application is directly proportional to its usability. The higher the usability, the longer, complex and difficult the migration. Why? Because there is less window of error, more user adaptability etc. Getting back to the point, example if an application is developed for something that is only used by a certain people, its working fine, there are no scalability chances, and the audience (the end user) are perfectly happy, applications like those do not need to be migrated versus an application that is used by thousands or millions of people then chances are over time we will start to see the above mentioned issues (in life of software as it is) and at that time migration becomes inevitable.
Understanding the system. Deeply
Among other things, we also need to understand the existing system deeply. No migration can be successful without understanding what the current system does and how. Only after once we understand the current application properly, then only successful migration can be planned. This plays similar role as requirements play in new software development, improper requirements lead to improper development and similarly not understanding what we are migrating and why, may lead to incorrect choices and inefficient migration
Benefits of the old system. Yes there are benefits
You might say that, when we are thinking about the migration, how can that application still deliver benefits. Yes it can and it does. The application was developed for a reason and chances are it is still doing some things correctly which are crucial to the system those things are the reason that application lasted till today. One should highly recognize it, understand it and should be ready to enhance or at least equate those things after migration.
Value of trained clients.
This goes back to development to usability ratio and this mostly falls under end user exposed applications. Since the application is used for a long time and the fact that it still exists probably means that you have some people that are using and know their way around the application well. No matter you don’t like the experience that they get when they navigate around, but they can and they still get some work done because of existing application. When we plan to undergo migration, those people should be highly valuable. The application is for your clients and should revolve around how its best for them to use it, changing it drastically will impact lot of people, example, Bad examples: Microsoft Windows, Evernote, Good examples: Gmail, slick deals etc.
Migration is a high impact change. However before migration we should analyze the correct reasons behind it. What persuades us to do the migration? One must answer this question before planning a new system. Is because we are doing more support then development? Is it because we look and appear outdated in front of our competitors? Is it because there is a better technology out there that can do the work we do currently, efficiently? Is it because we have a team that is more profound in a different tech/way of doing things? There can be numerous motivations behind migration and we should examine and identify those carefully so we can take right decisions when performing the migration.
Proposals and what does it solve?
After we have evaluated the motivation, its time about proposals, we should evaluate various proposals on migrations, explore different things and ways to do it. Time spent there can be long or short but one should definitely give it enough thought so that when you are in mid-way of the migration, there should be no moments like “Oh we should have done it this way.” Brainstorm, sleep over the solutions, and more importantly, should answer what does it solve? Does it stand behind the motivation that started this whole thing? Does it do anything extra? Does it take away anything? These are key questions and one should definitely think about it.
Try and foresee life
This one is the toughest and not always correct. However, sometimes there is a lot of effort going into this and there is probably a business model around the application, when we try and foresee life of an application, we should consider market trends, consider support life for the technology we plan to use in our proposals, foresee business requirement, product landscape, changing that might lead to migration. The reason we want to have some hint about it is because we want to compare our effort versus benefit.
Effort versus Benefit
Migration of a system to a new one is a big effort not to mention its a high impact change. Migration is not always the best solution and after we have recognized the problems, the motivation behind it, the proposals and have decent idea about the new systems life, we should always also compare the effort related to it with benefits. Are the efforts to be done justified? And we should hear it from more than one team example, something that may be more effort and less value to development team but can be of a high value to finance and accounts team etc. Overall for a product, are the efforts put up together to migrate to a new system should be well justified and well known. One can also not expect the migrated system to replace the old system which has been running for 25 years, point blank perfect the first time nor its going to be built in 3 months. Only when this is well known and established one should think about going forward with migration.
Client training versus user experience
One thing that is easy to miss is effort vs benefit is value of trained client as we discussed above and there change to the user experience. This also applies only to end user exposed applications but, one can be surprised how upset the new users can be when one changes / or take it away peoples favorite thing, remember the start button in windows 8? It can take a lot of effort when we try to find the right balance between our trained clients and perspective new users (who will probably expect the application to have the latest and greatest user experience). Be wise to consider and include those effort when do our comparison of effort and benefits.
Product Vision plays a crucial role when we make any changes to our application and when we develop any features in our application. We have said enough that migration is a pretty big and high impact change. It’s going to use a lot of resources and will take time. While we do this, we should make sure we do not divert from our product vision, the end goal mission and future features that are supposed to come in our application at a later stage. A good way to evaluate this, is to think about a product some years from now from company’s/product managers point of view and make sure that the new proposed system will fit in just fine. As a matter of fact it should be even more supportive of upcoming features.
We should evaluate and make sure that the vision the stake owners have for the entire product will not be disturbed by this new high impact change. We should evaluate the benefits of old system and benefits of new system and rank them against the product vision and make sure the change we are making is for the better.
Example if a product vision is to go native apps for desktop and mobile devices it might worth the effort to migrate the website but we should definitely consider migrating the back-end to a more restful architecture to support multiple clients.
Team is as important as product. Whether you are a one-man army or a group of incredible people, team evaluation is must when going such a crucial change. Evaluation of the team against current system and new system is a must do. Chances are that your team is highly skilled in current technology stack and therefore can provide great support and quick development, but not so adept in new proposed technology stack. This is not bad but it may take team members to adapt /learn and go get better in it as they are in any other technology. This is added effort and should be known across the team. You do not want to end up in a system where one or two person know the most about it and others are clueless.
So we have spent time and resources to evaluate the need for migration, the proposal of how to do the migration, the product vision, the team. We should be all set for migration right? Wrong. We still have some things to decide before we get to the migration. Cost is always an important point in every application. Does the migration in any way have more costs then previous? Are those costs justified? The answers to this may be quick but one should at least have it covered before jumping in the migration. The other factor is support to the current system. This is most challenging in small teams and migration is tough since the support for current system is dependent on the same team that is working on migration. These should be carefully examined before starting any migration project.
After deciding, “Yes” to migration.
Ok now you have carefully considered all the factors that we need to for a migration we need to decide how we are going to do it, is it something that needs to be done in full or in parts, they both have some things to worry about, If we go with full fledged migration, the correct time estimation is hard. If we go with partial than we should think about will our clients be able to accept the partial system? User acceptance is not easy with a partial system, no matter how great that partial system is.
One way to ease this is to apply the 80-20 rule when going in partial system, so we get done 20% of functionality that is used 80% of the time. If we are going full development, we should make sure, everyone understands that the deadline needs to be realistically flexible.
So what happens after migration, or even in process of migration when we decided yes to migration? Team training happens, each team player who is playing significant role in migration is bound to find something new, that is interesting or scary. Team players are bound to undergo adaption of new technology, software, means of coding etc.. Continuous refactoring happens, when we develop something with new technology, its not always “the best” at the first time, as people learn about it, they find new and interesting ways to do it, but its important to go back and refactor the old code to new beautiful, easy, simple to understand code.
So overall, migration is hard, but doable, we should think about all of this when undergoing or planning migration so that we can take well informed decisions. It should not be scary; it’s nothing less than a project in itself. Share away your thoughts in comments…
I am in general an aggressive (aggressive in getting my work done) software developer. I want to get things done as they come. I do not like a TODO items sitting around even though its small. This means working fast, taking quick decisions, using fail fast methods. It also includes continuous education to yourself from team members and web, educating team members, know the latest and greatest tools avail at your disposal and sometimes running an extra mile for team / organization.
I have had a privilege here at my job for being in the team that builds a continuously evolving website for almost half of the company. These people use this website as their day to day job. All the business that comes in, get entered in our system from this website.
That’s right. I work with my end users sitting 10 feet away from me.
We all know how its like to build a software and demo it to the client. This means often times there is criticizing, change in priority, new requests and more new requests. Sometimes on a good day, there is appreciation and respect.
With all this going on release after release, there can be a point where you can feel “This is what they ask for, that’s all they get”. Times when you know that the ask is not the best thing to do and there might be some other solution, but we keep mum because we are afraid of making the change. I have had these moments. You have had these moments. Everyone who dealt with a real end-user have had these moments. All these moments hinder motivation and our strive to innovation.
What we should (and our end users should) realize
They are not developers.
Developers tend to best understand another developers professional challenges. While something that appear challenging to end user might not be challenging for developers and what may not appear challenging to end users, might be challenging to developers.
Everyone is on the same side.
Everyone is working on a vision of a better product. Period. If you think this is not true in your case, then there are bigger problems.
Communication is the key.
Communicate, in your team, to end users and try and explain what you think is best and why. Paint the bigger picture. You may not always be right, but hey you may not always be wrong.
While it might not look that way, getting things done is sometimes hard in these circumstances. Here is what I try to do and recommend.
While it might not look that way, getting things done is sometimes hard in these circumstances. Here is what I try to do and recommend.
Have a vision of end product and work towards that
Without proper vision, nothing will go in one direction, Aim and develop.
Have a TODO list of what needs to be done. Every day.
goes without saying, organizing things is more productive
Think and design as much as possible before development.
You will always miss something. Its okay.
Update the design as things change.
Prototype key features / changes to my end users
Best way to avoid bad surprises at the time of demo and to keep everyone in the loop.
Share new ideas among team.
Brainstorming ideas with team members always helps, builds team.
Ask yourself, How can this be better?
Everything can be made better, its just the matter of how and when?
When you ask these things to yourself, the good software developer inside you will force you to do things the better way.
Take pride in your work
If you don’t take pride in your work, no one will.
Praise yourself and others on their hard work.
If you don’t praise yourself and your team, no one else will.
Obviously there can be more to it…
Do you work along side your end users? Be proud about it.
What do you do to make sure you are at your best everyday? Share in comments.
Developers are usually problem solvers, we solve problems and once we solve the core of it we have a tendency to call it done. However completing the rest of it, the finishing touches takes a looong time.
The 99% complete syndrome is a documented fact that aligns well with software development and developers.
I have noticed this in many people and not all are developers. Once they solve the hard part, rest of them is unexciting/boring/tiring to them. Do not get me wrong, that remaining part is also as equally important in a process of making a thing complete, but the drive is usually gone. I am guilty of this too, once I am done solving that’s challenging, solving that was new and interesting, the drive, the motivation slightly decreases.
Why is that? How do you stay motivated and driven to complete it completely?
This can really happen if you are working on a side gig, Once a thing is 99% complete and 1% incomplete.
Deep inside my heart, I wish that was it. I know it is not and I know I will eventually do the rest of it, but when is that eventually going to come? I do not know.
I also noticed that, if you are working in an office or a product driven by other people you may still have this feeling but then there is someone at your shoulders waiting for it to be completely complete and so you complete it. There you go, nagging works 🙂
I do not want to include everyone here, I know developers who will completely complete the product before saying its DONE, done whether its office or a project they do in their garage. I am proud of those guys and one can really learn from those guys. I hope you have seen or met some of these guys around you too.
Its good to have them around.
Here is what I do to keep me going on my side gigs in those times,
Try and set deadlines, real deadlines, the one that goes on the calendar.
Share deadlines with your close ones who keep you motivated.
Demo the product to people who can be nit picky.
Being nit picky is good. It leads you to become a perfectionist.,which is good. Most times.
If you have a TODO list, DO NOT check the item until is completely complete.
If you do not have it, have one. TODAY.
Credit yourself after completely completing it.
What do you do to stay motivated and driven after 99% completeness? I would love to hear