So I can finally say that I have wrapped up a nice and tidy 2 YoE so far, working in the same company. I thought I’d write up a post on what things I have learned thus far.
Goooooooood old estimations…The core of softwarer development! When estimating things it’s always important to:
Developers, especially junior ones, tend to estimate tasks based on their deadline, and not the actual time the task will take them. It is important for the estimations to reflect the time you need for the task to be completed, and not the time you need for the project to be completed in time. Otherwise you might yourself with an misplanned project and a rushed task in your hands. That’s a no-no.
When you give an estimate, make sure that it reflects the time needed to complete the task. You might think “of course it does, dufus”…well, no it doesn’t always. So let’s make it clear, a task should always reflect a piece of work from start to end, not something half-assed. If you are writing code for a new feature for example, the task and its estimation should be about implementing, functional testing, unit testing, code reviews…the whole package.
You’re building code happily for a while, using abbreviations for internal services like AS and RGM, writing them into commit messages, using them with your coworkers, writing them into tickets, into the code itself - and one day a stakeholder comes along during a presentation and asks you “wait…what is ‘AS’ and what is ‘RGM’”? You happily explain what those mean, like “duh, stupid stakeholder, how can you not know”, and then you get smacked with a “Those are wrong”. Boom. Day ruined. Ok, maybe not ruined, but moments like these can be very frustrating for a developer so its best to prepare ahead of time and protect yourself in advance.
When building the product or technical specifications for a project, make sure that there is a section dedicated to the language used to describe itself and its components. After these have been reviewed (with the rest of the document) you should be good to go!
On an alternate scenario, if a piece of language changes for some reason then make sure to go back to these documents and update them, and perhaps even let the team know that A = B now.
If you every ask yourself “Should I open a ticket for that?” The answer is always “Y E S.”. Do it. And do it now. That thing you just thought is valuable and chances are it’s gonna be lost in the ever-bottomless pit of things you were sure you would remember. You won’t. So just open a ticket, and worst-case scenario it’s gonna be obsoleted.
But, ok, for serious, there have been a lot of times where me or a coworker would hunt down a ticket we were “sure” existed only for it to never be found. Guess what, it was probably stuck in this “Maybe we should open a ticket for this” stage, without anyone actually ever creating the damn ticket.
A proper ticket should contain enough details to give enough info even to someone unfamiliar with the project. Give an overview, specify the problem and its impact, give pointers to the solution (code/pseudocode, links to the affected files or the responsible piece of logic, anything).
A ticket should:
Being a software engineer is a dangerous profession. Noooo don’t laugh, come back. Okay, it’s not very dangerous (if you ignore all the back pains & vision problems) but it can be very frustrating for yourself. There are a lot of times where due to a mistake, a misstep, a fault here or there, some bad communication or lack thereof, you damage your standing within a project or the company itself, and avoidable friction is created.
Oh yeah, it’s true - no secrets allowed, put all the dirty laundry out. You thing you’re gonna miss a deadline? Share it, and share it publicly - not in any private channel. You have missed a deadline? Dear god almighty what are you doing here? Send a message already! And do it in a public channel! You just made an architectural decision when you discussed a problem with a coworker. State. It. Publicly.
I could on, I swear. There have been a lot of times where you think “ok, this is clear” but the thing is, that it is clear to you and maybe only you. So, protect yourself, state it publicly so that it doesn’t come back to bite you in the ass - because it will.
But it’s not just that. It might be that one day an architect is gonna tell you x=1 and the next day support the idea that it is stupid to have a design where x=1. Having a message or a previous thread to point to always helps :)
Making sure that a lot of transparency is involved is so freaking healthy it’s unbelievable. It creates the proper image of an actual functioning team and it elevates the level of quality that can be delivered. Be transparent people.
You picked up some work for this sprint and mid-way through you realize that the tickets are crappy, or perhaps that the amount of work is too much. Well, you should very quickly state as much to your Product Owner, your Scrum Master, your team, your mentor, someone (and do it in a public channel). A developer shouldn’t try to rush their work to accommodate for bad planning, and they should make it clear whatever their trying to work on is not well defined. It might not feel important at the time, but it’s definitely important for the stakeholders, the managers, and anyone who cares about the quality of the team & the work that is produced and/or given to them.
Sometimes you may come out of a meeting and think that you decided on following path A, but others may have understood differently. Always make sure to clarify on “fuzzy” meeting results, and don’t do anything if you’re not sure whether a decision was actually taken. Even more, if during a meeting you see that a lot of buzzwords are being thrown around but no action points are being talked about - try to push for them. A meeting where nothing comes out of it is completely unfruitful and could have probably been a thread in your messaging system.
But even if the decisions were clear, after the meeting is over, it’s good to post meeting notes somewhere public and tag its members, so that it’s clear what was discussed and what the actions moving forward are.
I think it’s part of a company’s lifecycle at some point to have multiple teams, generating value either for other teams or for externals. The moment teams are separated I believe that each team should aspire to create its own identity. Create a logo, get a name, maybe get some goodies with the team’s name/logo on them. Most importantly of course, there should be clear quality & community standards within a team, as well and clear-cut mission & vision (although those should already be clear from the moment it was created).
I believe that all of these are necessary for a team to feel like a proper team, it makes every member feel like a member of something bigger, it makes them want to uphold a level of quality, and it makes for a more fun workplace.
Team events are a nice way to give to each team the time to socialize, discuss things out of the workplace, feel appreciated, and make them feel like they are part of something bigger. These don’t have to be status-quo events like Easter/Christmas dinners. They could be organized to celebrate a big success, or for some quality team-building while having fun.
That’s it. Just celebrate. Celebrate the good things. Celebrate new members. Celebrate old members. Celebrate amazing designs. Celebrate service launches.
Positive feedback & reinforcement are so damn important and yet often are lacking. A simple “amazing work guys” goes a long way.