Writing Code and beyond..
You can write code. What next?
As developers, we write code and that’s pretty much it. Of course brainstorming, finding solutions to tricky problems, training halfwits and meeting client expectations is a part of it, but it takes more than that to run a fully functional company, right? The devs are undoubtedly the nucleus, and without them any service or product based company would fall apart but like they say, it takes a village. Working as a developer for almost a year taught me a considerable amount about code but working in business development and sales, taught me plenty about what’s involved beyond writing code. Let me walk you through it by talking about certain terminologies as well as app development life cycle beyond a developer’s involvement.
What do we know?
Quite a lot actually. Of course we are engineers (or not) so we know all about that :D Then comes the training we have received traversing through C, C++, Java and JavaScript. Some of us are also versed with PHP, Python and what not. But, if it boils down to just app development (web or mobile) the flow is pretty straightforward. We receive design files created by a UX designer, write the UI code, receive the API documentation with endpoints (or create them if you are a back-end developer), integrate them, deploy if we have to and boom! Job well done. But if it was that simple, everyone would be running a company. This brings us to stuff that we are unaware of.
What do we NOT know?
There are a lot decisions to be taken and tasks to be completed in the development of a product before it reaches the devs to work their magic on it. And understandably, a lot of people with different roles need to collaborate in order to materialise the product. Here is an overview of the steps involved -
1) Planning : There is a business owner somewhere who conceptualised the idea and decided on a basic flow of the app in order to set the ball rolling. From the perspective of feasibility, viability to schedules and financial planning, they do it all.
This step involves understanding what problem is this product addressing, how are we solving this problem, and how is the business owner monetising from this. This is a far more daunting task than it may seem which the developers are usually unaware of.
2) Analysis : If the product has been outsourced to an app development company or a product studio (like ours), this phase may or may not involve a business analyst along with a member of the sales/business development team. Lots of apps offer payment options, various common features and screens (like login, sign up and the works), scrolling features, editing features, sharing options etc so what makes any specific app unique? It is the job of the analyst to sit with the product owner and figure out. Sometimes, the members of the sales/BD team are approached during or after this phase. In the former case, we may offer inputs based on past experience as to what the correct flow may be. These seemingly minute decisions ease or complicate the developer’s life in the coming future :D
After innumerable rounds of estimations and negotiations do we land a single project, and sometimes, not even then. Clients have been known to haggle for extra features and extra developers at lower costs while expecting utmost professionalism and top notch quality. Thank god that developers don;’t have to deal with that! Phew!
3) Design : There has been a long standing feud between UX designers and devs, each trying to establish superiority with maximum display of skill but the UX designer sets in motion and eventually locks the fate of the business owner, the product and the developer’s tasks in the foreseeable future. If any of us think it is easy to decide how to accommodate the umpteen number of features clients want in their product, think again. Let’s say we can encompass the features but can we do so without the clutter? Of course not. From decisions like which logo explains a particular action easily and which flow decreases the number of screens while providing maximum functionality, to choosing colour palettes that evoke certain emotions in the users, the UX designers do it all and oh so well!
4) Implementation : Coming to the wizards who code!
From managing app states to databases, it’s a tough life for the developers, but you have to admit, you love what you do! Solving complex problems, applying hacks, refactoring your code, merging PRs, even managing the Trello boards and task allocations. Undoubtedly, juggling multiple projects, training newbies and sometimes missing deadlines are a buzzkill but the the late nights and caffeine fuelled sessions keep you alive! Debugging, maybe not so much, but you get the idea. It’s not easy implementing a new feature or working with a framework that you have no experience with. It’s daunting to think that the tech space is ever changing and you have to keep yourself abreast with the latest frameworks and tools but that’s why you’re the champs ;D
5) Testing : Let’s not forget our QA engineers! They have a love-hate relationship with the devs because let’s face it, no one likes being told where they are wrong. But what would all the products in the world be without these unsung heroes? Buggy, that’s what! Sifting meticulously through our code and hoping they don’t (or do!) find an issue is a tiring job. But anyone who knows a tad bit about development knows that skipping this step is suicide.
6) Maintenance : Imagine a product that was conceptualised, designed, developed, tested and deployed and it crashes in production! Bam! As a business owner, you lose your user base, your market value and eventually, your hold in the market. Who can save your empire from collapsing? Yet another developer! Huh? You heard me. Each and every product needs to be maintained in order to adapt to the changing user requirements or to fix existing issues, if any, in the deployed code. This has to be the worst because not only do you have to work on an existing code, but you also have to sit and wait for the code to crash or for a new feature to be added in order to prove useful. Sucks, right?
How to find you?
Whether you are a freelancer or an app development company, now that you know the steps involved, how do you make sure that you connect with the correct people and get an opportunity to showcase your skillset? This is a tricky one. Some people may swear by marketing and maybe even SEO. The old school minds will emphasise on sheer talent but there’s no one correct solution.
A website sure helps. When anyone hears anything nowadays, the first thing they do is Google it and if you have a website, you choose what they see. A website is the first impression of who you are and what you do. It should reflect what truly differentiates you from millions doing the same thing as you. Adding to this, if you have a few successful products or open source contributions, that adds to your credibility. If those reaching out to you have used these products or OSS, great! If not, they can now and if it’s any good, half your work is done!
But not everyone has great products or OSS under their belt, right? In that case, what you can do is write wonderful blogs or articles (like this one :D) for people to read and get an idea of your expertise. Being listed on reviewing platforms like Clutch is extremely helpful. Add great review to that and you’re all set. The motive is, the more the sources, the better. If nothing works, there are always paid ads to help you out but those don’t come cheap.
Why are you the best fit?
Every developer out there feels they have the expertise (and more often than not, they do) to execute a project to perfection. But you need more than your own conviction to convince a client to trust you with their project and their business. What can you do to showcase your skills?
It’s great if you have been doing this for a while and have an impressive portfolio. However, all of us start somewhere and if you happen to be just starting out, you can showcase various experiments you have done that show your knack for complex problem solving. It is also crucial to have a company deck or a basic presentation that is concise but sends a clear message about who you are and what you do. For start-ups, having a social presence is more important than most would think. Twitter is a platform that is getting many across the world hired and fired, if you connect with the right people. Similarly, if we are talking about a company and not necessarily freelancers, then networking is very important. Company founders have a widespread network and these connections often help land great clients and wonderful projects.
Having said that, if you do land a project, make sure they end on good terms so you have great testimonials to bank upon and solid references that vouch for you. One success story leads to another!
Why to choose you?
If I am a client and I have managed to find you and you have shown me that you are good at what you do, even then, why should I choose you? We at GeekyAnts are early adopters of the latest technologies and frameworks and that has helped us capture a market while others were seemingly unaware of its very existence. The tech stack you specialise in definitely matters. It’s not much use if you are a React wiz and say, Uber comes to you with a Python requirement, right? Who would want to pass up an opportunity like that?
That being said, it doesn’t translate into learning all languages and eventually having an emotional breakdown. It just means, you need to be updated and have a team with a range of expertise spread across various tech stacks and you should be willing to delegate.
Someone once asked me if we should be talking in terms of expertise or experience. Expertise is mandatory (duh!) but no one spending the $$$ for their business would bank on a 19 year old with plenty of expertise but 0 years of industry experience. Harsh, but the truth. We are undoubtedly shifting from the “need to have 10 years of experience” perspective where devs with 5 years of hands-on experience are Engineering Managers at start-ups and are doing a marvellous job but nevertheless, some experience is definitely required. So get your hands dirty on as many projects as you can!
This will also indirectly help you give technical talks in the future and you never know how your business might boom from one talk video that someone saw in the past. What begins as a small talk at a meet-up may end up as a speech opportunity at a conference, resulting in exposure, networking and eventually, more business! These videos coupled with any side projects you may have picked up for fun but grabbed major attention along with any past work you have to showcase, will help seal the deal.
Can you show your work?
I just mentioned past work. But can you really show everything you have worked on? No!! You may end up with a legal notice. These projects are often done for clients (big or small) and are almost always bound by NDAs and several other legal contracts that prevent the development company from showing any confidential information to other prospective clients.
But then what do I do? You may ask exasperatedly. Take one client’s permission to show their work to the other! Get testimonials from them. Get great reviews from them! Make case studies of their projects and market the hell out of it! Make these clients your references! And anyway, if you have done the work yourself, the description of the project (with no specifics shared) and the knowledge gained from it should be enough for you to convince the best clients.
What are these terminologies?
Many times you may have heard of terms like engagement, additional requirement, change requests, billable hours etc but what are they? If I am working on a project and I have to write the code for 5 buttons and if the client asked me to make a 6th button, what’s the big deal, right? Wrong!
Each project goes through a scope analysis where the scope has been decided upon way in advance and the cost of the project is decided based on that. You doing any extra unauthorised work, is a loss to the company and eventually to you (how do you think they pay you?). On the other hand, if this request is duly authorised and signed off, if becomes an additional request! If it is a deviation from the agreed scope, it is simply a change request!
Now the engagement we are talking about does not involve any rings. This just talks about how the client is collaborating with us. If it is an entire team that is working on the project and we manage the project, the scope is fixed, the time and cost have been agreed upon. This is a fixed scope model. Whereas, if it is just a bunch of developers working with the client’s existing team, this is a time and material engagement. Which brings me to the horror story that is the timesheet!
It is a pain we have to live with but ever wondered why your company is obsessed with timesheets? The work you fill in a time sheet is sent to the client. If the client feels the hours and the tasks completed in those hours are justified, they pay the company. This money is used by the company to pay your salary. So next time you begrudge the timesheet, remember you are complaining about receiving your own salary. This is something I constantly remind the devs while starting a new project “no timesheet, no salary” and the never forget to fill those again :D
Why should you know this?
Like in most organisations, the developers just know the code part and not much beyond it. The details highlighted in this article are not always disclosed to the devs either because they are not relevant to your work or because this is an overhead for you and we don’t want the burden of a client to affect your work. So why did I waste 2000 words? So we can all be aware and contribute better and smarter. Knowing the ins and outs of business will help us empathise with our employers as well as our clients and help us give our 100% to our work. And that’s all anyone hopes for :)
