So today I want to talk about a number topics that are a mostly of a non-technical nature, but in my opinion are still important for any developer, more so for developers working in a startups, more so for junior developers. It is a common knowledge, that startups are rarely easy, they are chaotic, when you compare them to stable companies, so as a developer you need to apply different ruleset for the way you do your work, so that your software product becomes the best it can be.
Btw, even though in this blogpost I want to talk about some things that can be hard to digest for some, that doesn’t change the fact that working in a startup is awesome, it is hard, but that is a part of what makes it an adventure. You’ll meet new people, you’ll get to develop and learn things, that you probably wouldn’t get to see in a stable company. You’ll get to grow up as a developer and as a person. All that makes startups something, that in my opinion every developer should try at least once or twice in their career.
Before we begin, everything you’re about to read is based on my experience, so take it with a grain of salt and remember, that you are your own best advisor, because you are awesome!
This is my first ever blogpost, so if it stinks,,, I'm very sorry :)
1. Startups (and business in general) are not a hackathons.
Startup’s work rhythm can start to feel like a hackathon (when "make stuff work asap" becomes your nickname), but there is an additional layer of responsibility and thought that needs to be applied.
Your job is not just to create something that works, you must also detect potential problems, not only code based problems, but business problems as well, I’m not telling that you that as a developer you have to do the business part of things (you must if you are a co-founder), but whatever the case you need to understand it.
And code based problems? Solve them if possible and talk to your team about them if you are having trouble. Don’t keep it to yourself, sooner or later you’ll find yourself doing a task that has some hidden complications, that haven’t been discovered in process of creating a task.
Plus your solutions must be maintainable, resistant to change, so following best practices and patterns is very important, both as an individual and a team member.
That means SOLID, developer meetings, GRASP, pseudocode, best practices, design patterns, team communication, and other good stuff, that exists for a good reason.
2. function makeQuality(time, skill){ ... }
In a startup there is a 90% chance that you’ll get to do something for the first time, because being assigned to do different things is not uncommon in startup companies ( it does not seem like a good practice to me, but it is hot is)
Don’t get me wrong, you MUST know your stuff and keep learning for as long as you breathe ( yes, I’ve said it), but when you work on a job, where you have multiple specializations, you’ll get to the unknown regions sooner rather than later.
But in these kind of situations delivering top quality solutions, may take more time, and you must admit that and ask for help or more time if needed. Some might say, that delivering code that just works can do the job, but in my opinion that is an illusion. From my experience, you’re just creating a debt, bad code will cost you in the long run, and the bigger your system gets the harder it will be to fix the consequences of your past self’s bad decisions.
Note: Solutions that just work(no code structure, no code quality check) have their place in software development, you can do it once in a while, problems come when using those solutions becomes a habit and if 'just working' solutions are here to stay.
Note: I keep talking about top quality code, but let me tell, what I mean by that:
- it works and passes all the tests with good performance (thank you, Captain Obvious)
- other developers can easily read your code (or at least it is not difficult)
- your project structure, naming and organization is a result of a team’s communication, not just your imagination
- your modules/classes/functions follow DRY and KISS principles, all code for a given task is here, and only here
Note: One more thing, I am talking about top quality code, top quality software product has even more criteria(like “it must solve user’s problem”, good UX/UI, security etc.)
3. Communication factor.
Don’t close off, being a part of a team is not just about working on a project together. Let people know, what you are doing, tell them, if you are having trouble, help them if they are in need of assistance.
You most certainly need to be able to do things on your own, but by communicating with people, you can detect mistakes more easily, get different perspective on a problem and new knowledge, that can speed up the process and improve quality.
4. Ego factor.
I’m talking about the way you see your tasks, seeing them as an enjoyable challenges is awesome, it is a good thing, but again this is not a hackathon, someone is going to use your product, and they don’t care if you enjoy making it or not.
5. Murphy's law.
“Anything that can go wrong will go wrong.”
Not always, but this is something you should remind yourself about from time to time. It's not that you should be afraid of things going wrong, it's that you should not take potential problems likely, when you detect them.
6. Never stop learning and learn well.
Startup job can devour all of your learning time, that’s how it is, but again if that is the case, talking to your team might lead to a solution for that problem. Even if you find yourself in a situation, where there is no time for learning new things, it is up to you to find a way, to find time. Excuses can't help you, but thinking yourself and your team out of uncomfortable situation can.
Some might say "I learn as I go", and that is great, but learning on the go does have it’s flaws, most notable is not getting the big picture, when it comes to technology you’re using, as a result you are sacrificing quality for speed again, and code quality debt will come to haunt you and your company anyway, so is it really worth it?
So healthy learning patterns must take place in your professional life, for me it came out to be 40% theory and 60% practice and experiments. (I may or may not talk about learning how to learn in future blogposts)
As far as I know, trouble is coming, when your learning pattern is broken or non-existent, when you start feeling stagnation.
7. Get better not only at coding, but at communication and negotiating as well.
You’re doing everyone a favour by being approachable, easier to talk to, easier to cooperate with.
8. Work hard, work smart, work with passion, but don’t burn yourself to a crisp.
Working hard is a good idea. Finding productive ways to be lazy is a great idea. Resting from time to time, finding time for friends and family is the best idea you can get.
Part I - Summary
- do your best to avoid sacrificing quality for development speed
- learn to negotiate and communicate
- be disciplined as an individual developer and as a part of a development team
- don't burn out
- keep learning stuff, and make sure you have time for it
I’d say that’s enough for now, there are more lessons I want to talk about, there is too much for a single blogpost, so se ya in Part II
Photo by Nghia Le on Unsplash