5 Crazy Things You Learn When You Work For A Software Developer
By Alan Ryland
1. Believe it: no one knows what in the world it is that you actually do.
When people hear the word “software development,” they typically think of Facebook or Microsoft or Google. These companies are good at projecting an image of happy-go-lucky techies sitting in their comfortable offices while drinking tons of coffee and lounging in their myriad beanbag chairs. In contrast, we have plenty of coffee, but we’re still on the hunt for at least one bean bag chair we can share amongst ourselves.
First there’s a concept. Then there’s talk about the concept. Implementing that concept. After much bickering in the conference room, you need to have a team who can design that concept and bring it to life. Then there’s frontend development, which is the part of the web that the consumer can see and interact with and backend development, which is where all the magic happens and where user input is sanitized and indexed. Think of it as a digital assembly line: Code sorts and checks user input; complex algorithms are run to calculate and predict outcomes; then the decision on how to store the data for easy access in the future.
Once the design has been implemented, it needs to be TESTED! Quality Assurance (or QA) is a term we’ve all heard. Products are never rolled out to the market, ready to be consumed, until they’ve undergone a screening process to ensure that they are functional and intuitive as originally intended. Software has to be routinely audited to locate outliers in the numerous elements which govern everything from page functionality to whether the features provided are just that: features which do what they’re supposed to do.
All of this is entwined with the written code, the language used to create a virtual entity which the power and capacity to deliver on your business goals and the promises you’ve made to your customers (whatever they may be). A lot hinges on the success of the QA process because it is a constantly ongoing activity. In fact, it can be argued that time spent on QA is actually more valuable than actually crafting the software (not to say that the latter is not equally vital, let alone time consuming!).
Code can also break! It breaks.
All. The. Time.
All the time. Because it will decide it just doesn’t want to work with one element on the page. But how to identify that outlier?
#TheStruggleIsReal.
2. The office environment is not as mind-numbing as you may think.
Now that I’ve put you all to sleep telling you what it is we actually do (I actually ride dragons to work, but no one would let me write an article like that), I must insist that this environment is not necessarily as boring or as mind-numbing as it may appear on the surface.
Because the nature of our work is so internalized and can very well mean sitting at our computers in silence for any given stretch of time (us writers know this all too well!), we do feel compelled to talk with each other. We’re a rowdy bunch, a frat house. We’ve had a crazy office party or two. And while those are fun, the best moments are the ones like the time we ordered ice cream cake for the boss’s birthday and sat on the floor powwow style gossiping like high school students and spouting one-liners that should, in time, get us our own sketch comedy program on Netflix provided we continue to chow down on our ice cream while in mourning over the futility of it all.
On a slightly more serious note, startups foster a culture of self-sufficiency and sustainability. We delegate tasks as well as we can—by well, I mean “thoroughly” to reduce back questioning. When dealing with work as technical and as detail oriented as ours, the person before the next one in the chain tries their hardest to make themselves obsolete. Doesn’t really do anything to dispel the image of software folk as asocial and reclusive geeks, does it?
3. The layout of the office can be the difference between life and death.
Great communication is the life blood of successful software development. The reason for this is because there are so many different departments who have unique, vital information that may be related to just ONE specific part. For instance, a problem in development cannot rely solely on a solution within just development. In order for the solution to best address the customer’s needs, it needs to be a solution which utilizes expertise from multiple departments.
Let’s say that the programmer can’t run an algorithm because of how the data is inputted. Allowing them to provide a solution that is just going to solve their needs might inhibit or decrease user experience and decrease usability of the feature, which could change the way the product is sold. To a programmer, a line of code is just a line of code. Changing that code doesn’t necessarily fit into what the overall solution could be.
We work in a tiny space but we each have our individual offices. In contrast, I have a buddy who does engineering for Yahoo! where the office is set up in sort of warehouse like, with everyone at their own desks but right next to each other and thus, directly in contact with each other.
There are pros and cons to each layout. The biggest tradeoff is noise pollution. Since programmers often work on highly complex algorithms and lines of code, it requires them to sort through a menagerie of fitted, uniquely specific parts relying primarily on memory: Focus is absolutely essential. But when you have your own office, you can easily shut the door.
Maintaining a direct line of contact is KEY.
When no one does…HORRORS!
Don’t believe me?
Every bug, every enhancement and every fix goes through what is known as a ticket system. Is there a bug that needs to be reported? Open a ticket to document how you came across the bug in clear and easily understood steps. Is there an enhancement you have in mind? Open a ticket explaining what this enhancement is. In their simplest form, tickets allow those involved in every step of the development process to communicate with each other openly and to track their activity.
If everyone simply talked about these issues in conference rooms over coffee at ten in the bloody morning without documenting ANY of it, you can kiss any hope of collaborating efficiently goodbye.
4. Everyone and everything absolutely stops and screams in terror when the internet goes down.
Yes, yes, we are a society dependent on the internet for our very survival, but when the internet is down, you may as well add “Ability to survive post-apocalyptic mayhem” to the skillset on your resume.
We are a society that wants instant access to EVERYTHING, from our breakfast to our friends and, most importantly, to our DATA. This created a revolution in the way software is created. Software is now predominantly web-based. Naturally, the creation and testing process thereof relies on this mobility and web accessibility. In addition, the tools that we use also suffer from the same affliction: As developers, we are just as greedy in wanting instant-anywhere access to our tools.
When the internet is down, everything comes to a screeching halt.
Have remote collaborators? Forget them: Set them free. Say goodbye to any sort of bug testing. Say goodbye to your clients with whom you won’t be able to speak to with any sort of authority. And if you have tasks which need to be worked on that have all of their history chronicled and managed through a task management system like Asana or a cool little conference room on Slack, hop on that plane and get the hell out of town.
Face it, kid: You’re doomed.
We’ve survived one internet outage in my time here and three hours into it, I’m surprised none of us devolved into cannibalism. Being a writer in an office full of angry developers frightened me, so I hid under my desk.
5. Time and imagination can be your most significant limitations.
In order to satisfy customers and stay relevant, we conduct sprints—mapped periods of development to be completed in a set amount of time—because there is an invisible, ever permeating existential need to deliver results as soon as the request arises.
In contrast, being imaginative and creative requires an endless resource of that scarce commodity called time. The imagination our team brings to the job and the time we actually have to propel ideas into action is severely limited.
Good software is the product of relentlessly specific—yet damn near philosophical—conversations which set out to predict human behavior down to every single click. Then you have to throw your brainchild to the winds and hope people respond. When even the tiniest complaint might turn out to be that one outlier you didn’t think of (or possibly threw out) during your last meeting, you need to go back and start the process all over again.
Which takes up more time.
Which consequently makes you regret not spending enough time THE FIRST TIME.
It’s scary, even stressful. You might even find yourself mourning the futility of it all when you realize that every idea you have, no matter how good, has no basis in reality if it cannot be compartmentalized into the realm of human experience your website or your app is trying to game change and (hopefully) simplify.
We are a team whose entire strength and resolve rests on the shoulders of the five (sometimes six) of us who walk into this office Monday through Friday. That’s daunting, when huge companies such as Google or Microsoft have entire, much larger teams and resources at their disposal.
But even dwarves started small.