(I've got to say that this was meant as an internal memo, so there might be references that will sound weird for people outside my company.)
I've seen people spend a lot of time crafting notes for their teammates to document the right order of steps to accomplish a repetitive and cumbersome task.
Putting extra effort is a good thing. Going above and beyond is also a good thing. I think you should try regularly.
Some people like to present unit testing as something optional in addition to the code they produce. They usually talk about two options: they can either create good code or good code that comes with tests.
I just spent a couple of weeks doing TDD with somebody at work. He knew about TDD and unit testing in general, but he wasn't necessarily convinced about the trade-offs of TDD, especially for somebody with no previous experience doing it.
It will happen more often than not: after you finish estimating the work, you realize the estimates are higher than what everyone was expecting.
Great, capable individuals can definitively make a difference. I know a lot of them; sharp, hardworking people that could easily impress you with their knowledge after a 5-minute conversation with them.
Before sending an estimate for your next project, take some time and consider the following questions:
If you do a quick Google search for how to get better at estimating software tasks, you'll find multiple people recommending the way they do it. Some of these recommendations are some variation of the following ideas:
It's being a long time since I estimated something using a single value. Providing a range is usually a better practice, and forces a different thought process that's extremely valuable.
Are these the same really? I know that mathematically they are, but do they represent an equivalent effort for your product?
Where would you rather invest your time? Upfront to try and come up with a more accurate estimate, or throughout the project to manage around an inaccurate estimate?
"Prioritization" as in having a conversation regarding all the tasks assigned to the team and coming up with the best plan to achieve our goals.
There are three people in the room helping you out with an estimate. You discuss the next feature, then ask for everyone's opinion. A guy and a girl think it will be two days. The other guy thinks it will be five.
One of the biggest changes from moving to a management position after being a developer is getting used to having other people do what you've been doing your entire life.
Having values is something crucial, not only for your social life but also at work, to guide everything you do.
From our "Engineering handbook", here are several areas that you can focus on to make sure you achieve success:
For years companies have tried to measure developers using all sort of hard metrics, like the number of lines of code they typed, or the bugs they fixed, or the bugs they introduced, or how early they finished. It doesn't matter how you try to slice it, every one of these metrics can (and will) be manipulated, which makes them useless.
Here are some specific notes to keep in mind to help a software project get back on track. Some of there might not apply to you, but take a look and see if there's something that helps you get things where you want them to be.
Target dates you are asked to hit can easily become anchors for your estimates. This could bias the way you think about the effort that will truly take to complete something.
Just make sure everyone understands what your estimate means. You aren’t committing to anything by telling someone how long you think something will take. You are just giving your best judgment about it.
Some people like to talk about the best case scenario to complete their projects. Some people like the opposite, and they always refer to the worst case.
I've always thought that is my responsibility to protect clients from themselves. If not specifically mine as an engineer, then it's definitively my team's job to help them achieve their goals.
At Levatas, I've always worked with very talented people, so I'm not just honored but incredibly blessed for having a great team trusting me with such an important role.
Of course, the difference between finishing a 4-hour task early or being late is usually about time. "If I can only get another extra hour, I'll wrap it up for sure!"