Three roles have been evolving in software development over past few years.
The devigner is a person who packs a pretty punch. She is a graphic designer, UI designer, UX developer, server developer and database developer all rolled into one. Continue reading 3 Trends in Software Developer Roles – And One to Avoid!
At the beginning of this millennium, the PC/OS wars had practically ended. You used Windows everywhere. Only some companies like Mindfire, which worked on Apple Mac development, had any use for platform diversity. Everybody bought Wintel – because you had to. Software was made for Windows only in most cases, so being on anything else meant being unable to run most things you needed.
Then, several unexpected things happened.
First, Operating Systems. The OS landscape changed. Apple made a spectacular comeback, and working on a Macbook was cool again. Mac OS X flew high. And Ubuntu rose from the ashes of Unix and Linux fragmentation, unifying them and making a friendly Linux.
Second, the Internet. The web became dominant platform for app delivery. Functional software that looked grey and dull, was suddenly all over the colorful web. Chrome and Javascript/AJAX hastened user experience on browsers that rivaled native desktop software.
Third, Design. Or, the ascent of design. Apple led the charge, and the world of tech grew to appreciate design for what it was – the yin for its yang. And those dull grey apps died a quiet death.
Fourth, Consumers. Technology exploded from enterprise/business to the consumer setting. Revenue started skewing towards consumers – although that died an early death due to our next point.
Finally, Devices. In came the world of smartphones and tablets, which changed the meaning of computers. And led to the creation of cloud. And desktop platforms became just one out of many access points for the cloud. Which leads to the Internet of Things. Coming next.
All the above made desktop platforms a choice, since the world of computing was no longer restricted to the PC and OS you used. Today, consumers buy Mac systems and techies buy Ubuntu systems, without needing to think what they will not be able to do. Because they can do everything.
At Mindfire, we celebrate this victory of choice with a commitment to platform diversity. Mindfire is investing in Ubuntu and Macbook laptops, aiming to have at least 15% of our people on Macbooks, and 15% on Ubuntu.
Why is diversity important?
A rainbow is interesting only because it has all those colors.
Manager/Lead or Client – who should developers care about?
Neither.
Software developers in outsourcing companies are a harried lot.
Demands come from multiple quarters – Lead or Manager, Client, Colleagues – to name a few. Sometimes a CEO and other random people are also part of the group. In large organizations, Marketing, Interaction and other teams join the party. And often there are multiple people of each type above. Time is always running out. And sometimes none of these people agree among themselves! What is a software developer to do in such a situation? Who should s/he care about? Who is most important?
None of them.
Software is made for a purpose.
That purpose is to be used by people for something. The only thing that matters in making software succeed, is whether Users will use it. If Users use your software, everyone will be happy. If Users don’t care, everything is wasted.
All the people above – Lead, Manager, Client etc – are representatives for the User. They are people with good intentions, but they are maya – illusion – from the software’s perspective. The only thing that software cares about is whether Users use it or not.
Software that is used is happy software. Software that is unused is grumpy software.
It follows logically that if software cares only about its use, the developers of that software should primarily care about the User. Generally, Client and Lead and others are also doing the same thing – they are planning and prioritizing and designing and doing everything for final User.
But!
Your Lead may find a short-cut that ignores user. Your CEO may want something done that is good for your company but bad for user. Your Client may prioritize something where user is short-changed. On top of this, ego and personal views may come into play.
In short, sometimes (although rarely) these other players may not have user in mind. In such situations your duty is to ignore them. If you can make them see reason, good. If you cannot, you still know what is right and wrong, because you know who to focus on – the User.
Your final responsibility is to the User. Your job is to make good software that Users love.
As a developer, your User is unknown, faceless and often doesn’t exist except in the future. It is easier and tempting to think of the representatives as real, and the User as maya. At core, it is just the opposite.
But my Client pays my company! But my Lead decides my salary!
In the place-time continuum of life and careers, you will find that the experience of making good software is what you will carry forever. Everything else will float away. Your Company will change, your Colleagues will change, your Client will change, your CEO will change, your Lead will change. But that experience of making good software that users use and love and you are proud of – that experience of exhilaration, that pursuit of excellence – that will never go away.
As humans, we sometimes do what our head tells us, and sometimes what our heart tells us. But through it all, our conscience guides. Think of Clients and Leads as head and heart, and User is conscience. Client and Lead may tell you what to do, but let User be your guide throughout. As in life, so in work.
Use Users as your yardstick in all situations.
When in doubt, think of Users. When not in doubt, think of Users. Everything and everybody else is maya.
Alternatively called revolutionary and creepy, Google Glass has cyberspace up – up in arms and up for it. Hate it or like it, you can’t ignore it.
There are social, privacy and etiquette implications. Not surprisingly, places where privacy is paramount (such as dive bars), have banned Google Glass. This makes headlines because…nobody knows!
And then there are positive applications such as surgeons monitoring indicators without having to look away. This makes headlines because…nobody knows!
You can’t even put it in any one slot. Is it technology? Is it fashion? Is it vanity? Is it utility? Is it the first attempt at mass wearables? Is it the advent of the cyborgs? It doesn’t end.
If the downsides are mostly about inappropriate use or privacy concerns, the assumption is that wearers will never take them off. Given that it is easy to take off, it is is easy to see that people will just adapt and remove them at inappropriate places.
Consumer uses are highlighted by Google. However, I feel specific work applications will come up as developers and organizations re-imagine the possibilities. You can use live-streaming for experience-sharing among friends, or field support personnel can use live-streaming to transmit a malfunctioning machine’s innards to an expert. You are an augmented human being with capability to see additional relevant information to the task at hand.
How can custom software development be impacted? One idea: a constantly recording Glass app with N-recent-minutes recording will mean that testers always have access to what they just saw – elusive bugs which cannot be reproduced will always be captured.
Every industry will have ideas of its own on what Glass can do for them. If Glass can make nurses more accurate, real-estate agents more responsive, students more attentive – you will use them.
Will you look uber cool or downright stupid wearing them? Will you care, if it helps you do things better and faster?
Let us meet someone interesting today.
One of our software engineers at Mindfire, Tadit Dash, was recognized by Microsoft this week as a Microsoft Most Valuable Professional (MVP) for South Asian region. His Microsoft MVP profile is here. You can read about Tadit’s journey here in his own words. On tech side, Tadit does his stuff on ASP.NET web development and Dynamics CRM.
It is wonderful to observe Tadit’s enthusiasm and vibrant participation in the global developer community – mostly at CodeProject and also on StackOverflow. Excellent.
Tadit has done all of this while being on projects constantly, and with continuous happy delivery for all projects he has worked on. Brilliant.
When desire and direction combine, time bends to the will.
Tadit is a great example of the type of people we want and love at Mindfire.
People who love technology, people who want to connect, people who want to carve an identity for themselves, people who are responsible, people who are passionate. People who are bound to their own work and talent and reputation and identity – not within the boundaries of an organization or role, but floating on the unchained melody of the unbounded universe.
People who intuitively understand the obvious – things like companies and designation and salary and teams and projects will come and go – what stays with you for your life is the knowledge you gain, the reputation you build, the well-wishers you have, the abilities you possess.
People who see beyond, and rise above. What fate and fortune give, they multiply.
I have never met or spoken with Tadit.
His story inspires me. Coming from the small town of Nayagarh, Tadit joined Mindfire at Bhubaneswar 3 years back. After proving his worth at work, his voluntary energy led to responsibility for “extra non-work stuff”, and subsequent awards, at Mindfire. He moved ahead to receive a CodeProject MVP award few months back, and now he has received the Microsoft MVP recognition. That’s not all.
He is not only Mindfire’s first Microsoft MVP, but also the first Microsoft MVP from Bhubaneswar, a city with 10,000 software engineers! Wonderful.
If Tadit can do it, so can you and me.
Be awesome. Be Tadit. Look beyond today – build a brilliant tomorrow using today.
Let us think about this story over what is, hopefully, a happy and inspiring weekend.
Cheers!
Recently I came across an interesting programming situation.
Parts of a web-based system stopped working suddenly, with nothing significant having changed. After some finger-pointing and accusatory guessing, it was discovered that some scripts on server side had been shifted from /root/1level to a deeper nested folder, let’s say /root/1level/2level. So far so good.
What happened next? Why would that make a system stop working?
Code needed to find path for some processing. The code split on first backslash to find file name, implicitly assuming that the file would always be one-level deep from root. When the file was shifted into a deeper folder, the path extraction stopped working.
There can be arguments about whether the admin should have shifted files into a deeper folder without informing developer, or why this should not have been done at all, and so on. But I consider this a clear elementary programming mistake of the hard-coding variety.
Hard-coding does not mean just typing in numeric or string literals into code, although that is the obvious college-level hard-coding. X = 420 or sEndDate = “1/1/2022”. It also means any type of inflexibility embedded right into the code and program. Hard-coding means not understanding the need for flexibility and not writing elegant code that can adapt to its surroundings.
Hard-coding is called “hard” coding because anything hard cannot be molded to suit the need at hand, because it is inflexible. Like when you put in an assumption that your file is one-level deep,, which makes it inflexible to run when its level changes.
What would be the right way to deal with this?
Step 1: extract path in a loop, so that you can handle any level of folder-nesting. You don’t assume you are N levels deep, because folder-level is not something that can be assumed! Instead you traverse the path to find how deep you are.
Step 2: Back-slash? Welcome to multiple OSs! The file-separator character itself is hard-coding. In every language worth its salt that runs on multiple OSs, you have operators to find environment variables including file-path separators. On Unix/Linux you are “/”, on Windows you are “\” or “/”. On Mac you had “:” long back during MacOS, and now you have “/” on OS X with its Unix core. And then I was on some Solaris/RISC machines decades back which used “.”.
Should you hard-code assumptions about N-level nesting and separators? Absolutely not.
Does it need extra time to write flexible code? Absolutely not. The amount of time you spend later in not writing tight right code in the first place, so much of debugging and frustration and rework – it would all be avoided if it were first-time right. And to write above path-extraction code in a loop with separator detection rather than hard-coding – you are talking about couple extra minutes. Take one less leak and you can find time to do the right thing!
Is it rocket science that an average programmer cannot do? Absolutely not. Once you decide to do things like this, it is pretty easy actually.
Then why do people not do it?
Because of mediocrity. A mediocre mind is happy with sub-standard work that somehow passes through. Because of lack of involvement. When you are pushed into a “career”, you are least concerned with your quality of work. As long as the next raise comes around, who cares! You are not a craftsperson to take pride in work, you are just a code jockey.
This, ladies and gentlemen, is the difference between a good software engineer and someone who just gets things to work. A good software engineer anticipates need for change and does things first-time right. A good software engineer thinks ahead and does things in flow during first-code which take very little additional time to do. A good software engineer does not hard-code, either directly as literals or indirectly as implicit assumptions.
Someone who is just a programmer does not do any of the above, and just somehow gets things to work – never sure when it will fall apart.
Now you decide what you want to do.
My first day at Mindfire and I already have an inferiority complex that all my peers, colleagues are Adobe certified. I have the experience in the same technology but not the certification. Which one is better? Or is there a better one? Or we need both? Not able to answer the question, first I decided to live in my comfort zone, with what I have and “prove myself with quality work”. But the second day again went with the same dilemma, looking at sample resumes that titled Adobe certified, in our company’s format.
Hmmm, I have the experience and knowledge, then why this hesitation of taking the examination for certifications? Well, these days when development platforms have syntax “help” and there is “Google maharaj”(Google GOD) for rescue, maybe I didn’t trust my knowledge enough and fear of not clearing the exam stood by me.I was still in two minds as I went back home, where my daughter was going to learn skating. As soon as she wore her skating shoes, she fell badly and my elder daughter said “Diya, get up! Dar ke agey jeet hai (popular advert slogan, which in English roughly means “to achieve victory, you have to defeat fear within you“) With a smile I realized this was my moment of learning from my kids, and decided to flush my fear and go for the certification. Hands-on experience certifies that I have the working knowledge to face a variety of tasks, which may or may not have training programs as prerequisites. At the same time, the certification itself would exhibit a determination and dedication to learn and improve.
A credential alone doesn’t guarantee real-world job skills, but in shortlisting and selection process, it increases the odds that the person is competent. With an ever-growing IT market, companies know competitive advantages help clinch deals and technology certified employees can be selling points. Following are some benefits of an academic credential, that I realized once I decided to take the certification and thought of sharing it with people like me who are still fighting to venture out of their comfort zone.
Having said this, I just don’t want to pass the exam with the easy means available, but by increasing my knowledge base. There are people who see certificates as badges to adorn on resumes – They are real assets only if you get them by working hard for them and are superficial if you have grabbed them through easier means.
3. Peer pressure causes loneliness, beer pressure causes belonging
When you choose peer pressure, you are alone – every friend is a peer is an enemy. When you undergo beer pressure, you know you have a purpose, a mission, and you belong to a worldwide movement called “No Bottle Left Unopened” – all in it together.
4. Peer pressure is a complex path, beer pressure is a simple path
Complex is the person who cannot get away from comparison. Peer pressure takes you down a complicated path built out of competition and deceit, slyness and jealousy, envy and hatred. Beer pressure generally creates for you a straight and simple path, generally to the nearest washroom.
5. Peer pressure makes you mad, beer pressure makes you glad
Peer pressure = can’t get badder
Beer pressure = gladder in the bladder
Mathematical justice for poetic art.
6. Peer pressure implies hierarchy, beer pressure means equality
Comparison inevitably assumes that there is an underlying hierarchy of superiority and inferiority, of humans stacked on an unequal ladder. Beer pressure assumes nothing and believes in fundamental equality of humankind. You build an equal world glass by glass.
7. Peer pressure is measured in numbers, beer pressure is measured in decibels
Peer pressure is based on comparison of numbers. Exam scores, weights lifted, goals scored. Numbers don’t have personality. Numbers are drab. Numbers are black and white. Decibels, on the other hand, are colorful. Beer pressure is measured in decibels. Decibels come in flamboyant red and flaming orange and fantastic indigo and fabulous turquoise and f… perhaps we should stop here.
8. Peer pressure kills, beer pressure fills
No explanation required.
9. Peer pressure is free, beer pressure costs money
True. But free things are not necessarily good things. And beer pressure does invariably cause free speech, so there.
10. Peer pressure is driven by expectation, beer pressure is driven by desire
You truly shine when the person inside you can come out and shine. Peer pressure hides your true self, since you act as peers cause you to act. Your life is driven by others, from outside. When you enjoy beer pressure, your life is driven by you, from inside. That is when you truly shine.
11. Peer pressure means a small view of life, beer pressure encompasses the universe
Restricting our world view to our immediate others – our peers – is such a limited view of this wonderful world we live in. Break those barriers. Adopt beer pressure and you will feel at one with the universe – vasudeva kutumbakkan – which may someday lead to world peace. It is our duty to try.
12. Peer pressure elevates performance, beer pressure elevates
There is an argument that peer pressure can also be healthy competition while beer pressure is unhealthy consumption. I agree that peer pressure can elevate performance under the right laboratory conditions. However, my learned friends forget that beer pressure elevates – period. Doesn’t matter what – performance, life, friends, family, memory, mood, work – beer pressure elevates all. Indeed, there are frequent instances of elevation leading further to levitation.
And the winner is…
Evaluating with a fair mind the dozen arguments presented above, it is crystal-clear that beer pressure wins over peer pressure. Peer pressure needs to be banned and banished, and a movement has to begin for beer pressure to be made mandatory.
Some readers will oppose this conclusion even after agreeing with above arguments – submitting unconsciously to the very peer pressure they need to oppose. However, please understand the simple significance of this matter. The future of world history depends on what we do today. Let us build a culture that wipes out peer pressure in favor of beer pressure.
Relevance to Software and IT Industry
Leaders and managers in software companies especially, have to build maturity and responsibility in their software engineering teams with young people who have just been liberated from years of peer pressure. This is a tremendous challenge not to be taken lightly even slightly. There is no better path to this goal than beer pressure. The way to build team spirit is to do it with spirit.
I hope all leaders recognize the dangers of peer pressure, and promise not to use peer pressure to create differences among people in pursuit of “better performance”. Instead, use beer pressure to bind people together. Performance is science, togetherness is magic.
Peer pressure is for losers. Peer pressure is un-cool. Cool is the person who is incomparable, for s/he is peerless. Be yourself.
Down with peer pressure. Hail beer pressure.
Cheers 😉
Author – Chinmoy Panda