Destroying the bot within
This is an article about my particular way of looking at the software development industry. It is not, in any way, a perfect theory or a strategic manifesto to reach a particular goal. It is rather a stack of ideas and concepts that I believe in and I use every day to carry out my life as a web-designer-slash-novice-developer in the most humane way possible. For this reason I know that some of you may feel identified more and less with the following paragraphs below and, I hope, only a few will be in complete disagreement. But that’s what it’s all about: not to think that you have the absolute truth, but to try to help others in the same way or also to grow in dissent, as a friend of mine says.
I will try to take a close look at my more than 15 years in the industry as a freelancer plus the last 5 years in a company to delve a bit into a concept, for me, more vital than any post in stackoverflow: the human part within a technological system. If you stay until the end, you will learn something useful.
I will start by clarifying that from my childhood as a designer, when I was still using wysiwyg editors, or even Flash (OMG), designing web pages for my friends, my goals were more humanistics: I was aiming to be a poor but honest painter / illustrator and talented as well (I expected that, at least). At that time the web universe was pure and exclusively another tool to “paint” the world around me and gave fuel to my poorer rather than talented future, to tell the truth. Hence, the vision of my current guild is a bit “tainted” by agents outside the software development industry.
I’m not a the-binary-code-runs-by-my-veins type. I made a different path. What gives me the possibility of having different tools in my backpack of experiences, as well as scholastic deficiencies that I try to supply every day a few by learning as much as I can and facing any challenge that makes me a better professional.
My last few years I have worked for Virtualmind, where I learned everything about work modes and formal knowledge about agile methodologies and work organization almost aseptic when handling the code. I have learned that you can work having fun and enjoying what you do, too.
GEARS MUST FIT — TEAMWORK!
When you are working in a collaborative environment, that is, with someone more than you in a project, the keyword is teamwork. It doesn’t matter if you are in an isolated branch of the project, it doesn’t matter if you work on a specific aspect of the implementation. I recommend you to see it as a WHOLE.
The results on a project will always be more complete, enriching and robust when everyone is on the same page. This does not mean that a developer has to style the headers site or the QA modify SQL tables. It means that all the parts of the workflow depend on everyone, to a lesser or greater extent, and everyone can contribute with their knowledge. What if a QA can prevent a wrong behavior BEFORE the developer invests programming hours in an ill-conceived flow? Perhaps a dev can warn a designer in time that the animation he is about to offer to the client is impossible to do in the site’s current structure?
This is why brainstormings and conceptual meetings are extremely important. But even so, without the formal framework and without the need of the bureaucracies for room bookings, without creating calendars with team members. It is very easy to approach someone’s work station and talk. I haven’t enough emoticons to express the importance of chatting, talking face to face with your co-workers.
It is understandable that Slack, Skype, an emails can be very useful or in certain cases even keys to make an enquiry, but dialogue must always be prioritized as a method to exchange ideas. This scares a bit of anonymity, impersonalization and disinterest and, on the contrary, encourages a more interesting and complete result. In addition to giving us a break to be with our faces stuck to the monitor.
In my particular case it is essential to work side by side with people I love, respect and even admire, to feel that network of professional and animistic restraint that encourages me to throw myself with any new crazy idea.
A working team united and in tune will always work better than a group of devs working as individuals. By knowing each other better they will know their strengths and weaknesses and by the synergy of the relationship they will fit in such a way that each one will do what he/she likes the most and the result will be less stress for all and an optimal group performance.
Obviously you can have — and usually will have — a work team where its members do not know each other or who simply by force of professionalism carry out the daily tasks. But here it comes the role of the company as an unifying agent that defines what identity they want to have. Clearly, the company can not “assign friends” or force relationships — that happens spontaneously — but can strengthen and stimulate the bounds when they are found. At the same time, ideally you should actively seek certain friendlier characters for the company philosophy to follow, beyond working/programming skills.
I am lucky to have many friends in my workplace. I share projects with some of them, even. And I can assure you that they are my reason to arrive every day at the office. They are the reason why I look for shared projects to be better every day and I try to contribute the best in others projects: purely and exclusively to facilitate the experience for my friends.
The work complicities end up transcending the afterworks and vice versa. Codes and conversations without words begin to appear. The fluidity of work grows and becomes more effective and with a better quality, because you do not only care to do YOUR part of the work, but you also have to care about your teammates’ work too. The egos are left aside. No one knows more than the other. A general single knowledge is enhanced. It is necessary to leave the usual vision of MY work to think more about OUR work.
And another added value is learning, because one capitalizes each new knowledge — which in a relaxed environment is much easier to assimilate. In my personal experience, I learned infinitely more by solving difficulties along with colleagues than by watching pluralsight videos. It is a senseless utopia to think that a single person can cover all the bases involved in good development.
A full-stack developer can be good in many areas, but having the resources of many professionals and specialists in certain areas together always works better and more efficiently. What is more exciting than new looks on the same problem that overwhelmed us for hours? What is more useful than the review of a colleague not only with other knowledge but but also with another experiences? How much time did you spend thinking about an “impossible” failure until someone else came, and with a fresh and different perspective told you: “there is a missing comma there” and that was the solution you were looking for?
In no way can I call myself a developer, but the amount of things I learned from the devs that cover my back every day make me a much more prepared designer, and have changed my way of thinking and seeing a project. A good designer has to know about design, but a good designer within a team must have new skills. Not only you design a slider for the application, you design it so that a colleague does not tear his hair out when he has to insert a knockout binding there.
In this industry it is better if you shake off the square philosophy of “this is as far as I will get”. Take one more step, leave your comfort zone and take the risk of doing new things to really grow. Listen to the suggestions of others and try to participate to make projects not only better, but that reflect a part of you.
On the other hand it makes me very happy and a little proud that many of my fellow devs are encouraged to style new pages. As part of the gear, I even try to make even the design easily maintainable for those who are not familiar with it. Adopting reusable, semantic styles, understandable to all. I’m not interested in being indispensable because a dev cannot change the background color of a form. I am more interested in being indispensable because I can make anyone capable of style a form without any help.
The designer must be a designer and the dev must be dev, but how much more a project grows when the developer is a little designer and a designer is a little bit dev too? Luckily, I work in an environment where both areas communicate and, with a few exceptions, each tribe respects, values and boost each other.
A system is not something that is done individually, it is made for a lot of people.
THE TENDER MACHINE
The software industry is going through an idyllic time compared to other sectors. Our efforts make daily activities more dynamic, simple and attractive for thousands of lives. It’s crazy when you think about it: today, somewhere in London someone is using a system designed by me, while in a town in Philly someone subscribes to a newspaper thanks to the interface that I have helped to build. The user does not know that I created it, but there is my work, anonymous but definitive; virtual but concrete.
I think it is very important to have that vision of work, to abstract from the intangible, to forget divs and classes and to think about human beings interacting with our creations. In a way we are the artisans of today. Generating tools to improve — hopefully — the lives of people around the world.
For me, this is a must. The fact of thinking that when facing a project we are going to dedicate hours, days, even months of our time and effort into something, not just a task, not just a bug or requirement, but an act to improve in some aspect the reality as we know it. I strongly believe that this is the way in which great applications are generated: from humanity. Because, ultimately… are we not humans? Are we not working for humans? With humans? The tools are not important. First we must think about the goal. Then we will see how we get there.
Previously I wrote about my first days like wysiwyg-designer. Today I understand the “bastardization” of that label within the guild, but at the same time I think: knowing code is great because it helps me to make an application more efficient, to make it smarter, to think about its development the other way around. But I also think: if the goal is to do something that helps other people in a way that was not contemplated, does it really matter how I did it? There will be time to improve it, to make it more performant, to think about breakpoints for mobile views, to do commits that generate a historical follow and the possibility to rollback when errors occurs, but… all that slang that makes sense today… should not prevent the creation of an idea. They are useful tools, but the heart of what we do is not the code, we cannot think of it that way, but we have to catapult our fingers on the keyboard for a more important purpose than to satisfy our developer egos.
Start typing when you have understood the soul of the project. Assign a task when you understand the impact within the entire system. Add a new div whenever you think it is really useful for the person who is going to see it as a vital block of information. First is the idea, then the code.
FINAL NOTE
At the beginning of this article I promised you that if you read until the end you could learn something new. In case that all the previous words have not given you anything: the new property font-display, which improves greatly the performance of the font-face load, stipulates a browser action at the time of loading a given font. It still does not have a large native support in browsers, but its implementation does not affect negatively the performance and, on the other hand, can improve the usability. For more info, take a look at this article and this one.
Check our Virtualmind magic ✨
Our website — Facebook — Twitter — Instagram
