10 things to live by software developers/analysts

I am no engineer. I came from the quiet life of being a sole developer turning requirements into life with hardly any human interactions. It’s a world of resourcefulness where formulating solutions seems like a never-ending chain of discoveries. The best part has always been “cracking the code” in your own style especially after hours of nerve-racking trials and errors.

This world can get pretty exclusive, though. Until some point when I decided to step out of my comfort zone to challenge myself some more. Hence, the following:

Communicate well. This means so very well. From e-mail and chats up to personal communication. It’s the key to almost everything (not only in programming). Always aim to establish a clear understanding between parties; to make sure both are on the same page. Don’t be afraid to ask questions. Don’t forget to take note of answers. At the same time, don’t hesitate to share what you’ve learned to those who also want to learn.

Consult. Just like there are many directions to reach a certain destination, there are also plenty of ways to approach a solution. Programming is pragmatic. The best solution is almost always a product of more than one mind.

Speak up. Discuss a problem. Share your insights. Give ideas. Cite an observation. This is a good quality of a team player.

This is quite the challenge for me being totally aware of my reservations. I work on it by initiating person-to-person conversations rather than virtual. I participate in initiatives. I facilitate learning sessions. But over time I learn that one of the best ways to communicate is to listen.

Be diligent. Research the facts. Know the dos and don’ts. Take a good look at the bigger picture first. Know what you’re dealing with. Measure the scope of a system’s functionality. Find the limitations. The most efficient and most effective means to do so is to communicate. Learn the basics. Study what others breathe for particularly those with expertise. Have a go-to person for a quick inquiry. Be independent but know when you need an outside intervention. Step 1. Always remember the first step.

Be articulate. Know the importance of a well-structured inquiry. As much as a good conversation or a quick meeting looks easier, a detailed discussion via e-mail can also serve as a reliable documentation. Expounding a thought electronically is definitely more challenging that I personally review my own writing up to five times tops before I hit send. That’s why wordings are just as essential. Requirements can easily go from general to in-depth that the ability to relay information in both high-level and technical languages is pretty much a skill. This takes practice that will definitely come handy once achieved.

Be precise than concise. There is no easy way to explain a complex concept so clearly but breaking down every detail helps. One thing can quickly mean another thing depending on the choice of words. Tip: the simpler, the better. This has to be one of my recent discoveries; that I need not to be witty or to use fancy or too formal words. The gist just has to be clearly present in a way that can be understood in one go.

Know when you’re right and when you’re not. Trust the code. Question the code. Know when to duck or bend over. Know when to stand firm. I take this as one of the most important because for one, this is applicable in our everyday life regardless of profession. There are lots who are more experienced than we are and sometimes we tend to just agree to settle things quickly but this doesn’t always has to be the case.

I remember dealing with a mishap for quite a while regarding a code change that I didn’t think as necessary in the first place. I wasn’t firm of my own. From then, I began to explain my thinking and my reasoning for the purpose of standing by what I think is fairly right. This can be a test of judgment but the important bit is to live by your choices.

I still take a step back at times due to levels of uncertainty but I secure myself by working twice as hard. Have as much faith in yours as the faith you have in the people you look up to.

Manage time wisely. Responsibilities just expanded, enter multi-tasking and time management. Sorting tasks per day is a good way to maintain focus and to properly exhibit the needed skill for the day. Example: all documentation tasks for today, coding tasks for tomorrow, administrative tasks the next day etc. This way the mind does not struggle too much to keep up with the variety of work items. It’s easier to work on a steady pace than repetitively put a task on hold.

I used to be very particular on the things I have to do. I usually do my best to prevent work from piling up as early as possible. Now I’m learning to appreciate the art of cramming (if I may say so). Heavy workload could also mean high levels of productivity and longer periods of being in the zone. No idle time. This can also get stressful but always a learning experience anyhow.

Anticipate without creating potential problems. Allot more time for impact analysis if possible. Be creative. Think outside the box but not too much. Avoid shortcuts. This means weighing the actuals versus expectations.

An analyst cannot rush into conclusions without any proper investigation. Having this job makes sense to me for the reason that there’s always a solution to a certain root cause; there’s always an explanation behind. There is a pool of possibilities waiting to be discovered while an attitude can also be developed in the process like perseverance, flexibility, mind-setting and powering through. Endpoints are usually rare. Better yet, we decide where the end of the line is. Pushing boundaries is part of the job.

Recognize people’s differences. Be proactive. Adjust if necessary. Be flexible. And this is not limited to this field alone. Just as there are many kinds of tactics out there, so as the different “styles” of developers, analysts and engineers. Respect other people’s way of working things out while sticking to your personal way of dealing with stuff (Step 5). The remarkable way is to inculcate effective habits to other people especially in difficult situations. Think about the “win-win” setup always. This way conflicts can be prevented and benefits for all are open.

Take ownership. This doesn’t just cover the good but more importantly, the bad outcomes. Taking credit is usually the easy part but taking responsibility, not so much. The road to redemption is rough that it’s usually just a neighborhood away from “giving up” or from “second-guessing.” Fight back against the negativity. No matter what, hard work pays off. A good man in the storm takes charge come what may, that’s what ownership is about.

Re-focus. I learned from a colleague a healthy working habit: the rule of 25-5: 25 minutes of uninterrupted work and then 5 minutes of slack. Our minds can use little breaks from time to time. Some may say this can cause losing momentum, others are simply hard-working. The idea is to just allot a few minutes for the brain to think clearly by unloading information for a while. Instead of pressuring ourselves to non-stop working, try to take short but frequent relaxation time to breathe. See the results and build your own habit from there.


5 thoughts on “10 things to live by software developers/analysts

  1. I’m still not yet finished reading it but the things you have shared would help people work better. Ayos din yung pagiging diligent mo sa work because important yun when making requirements come to life.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s