Table of contents
My career evolution
Things I wish I had started doing earlier:
Write a work log
Leave the comfort zone
Be curious a...
For further actions, you may consider blocking this person and/or reporting abuse
I have 20 years of experience as a software developer / architect and I pretty much agree what you wrote here. There are a couple of points I would like to make:
I guess writing a blog about your accomplishments is a pretty good proxy if you cannot publish any source code. However, if at all possible, publish software projects – hobby or work related. You create software for living so you should demonstrate your skills by publishing source code, not blog entries.
Sometimes big changes require big rewrites and the most important thing about those is having the main developer of those changes available whenever those changes are merged to the work other people are doing. In case of Git this would be merging your changes to master branch. We have a rule for our team that if you're going for a leave or holiday, you don't merge your branch into master, even if it has code reviews done and it passes automated tests. You want to have the documentation as you described but you also want the developer to be available to answer the small details which are always missing from the documentation. The only thing that can describe all the details is the source code, everything else can give you more or less overall picture only.
Other developers can replace you if they have the documentation and source code but that replacement will be less effective than having the original author available. I'd say reserve at least 2-4% of the total work used for the big rewrite for the time reserved to support the newly introduced code after the merge. For example, if the branch took a year to write, you reserve the next week after the merge for supporting the other developers. You can do some best effort work during that time but your primary task is to support other developers with the new code. You definitely don't take a leave there.
We use Git and rebase workflow for everything, so keeping the "ready" branch off the master until you return from the leave is no problem. If you don't know how it works, learn to use Git effectively.
And about the meetings and disagreeing on things. I think it's fine to express this during the meeting if you can keep the discussion to matters and facts. Expressing something like "I'm against this action because it causes side-effect X which would lead to Y" is not only okay, it's the recommended way to proceed. However if once you start to speak about persons and opinions (or even beliefs), it's time for 1:1-discussions instead.
And I would like to add one point not in the article: keep learning new stuff all the time. I'm always balancing how much new stuff I learn vs how much I use the methods that I already know. It's hard thing to balance but I think it's absolutely required if you want to stay relevant and effective when better techniques become available. And if your employer cannot agree that you can use some of your paid working hours for this, your salary should be good enough for the working hours that you can do the same thing on your own time without feeling ripped off.
Other than that, great work!
Hello! Thank you for sharing this valuable message, I completely agree with all of it!
For the big rewrite part, here is some additional context that was not mentioned in the article. I was overconfident. All the use cases were covered with automated tests (not saying 100% code coverage, but 100% use case coverage). I was confident it wouldn't break during my absence, and it felt like a pretty good accomplishment to fully release that rewrite right before leaving. The problem I didn't anticipate is that one of the most critical use cases was wrongly tested: I assumed the system would behave like A, so I tested all the possible cases for A, but in the end it behaved like B.
This is problably something I should have written in the article:
Don't make assumptions, always ask questions.
This may involve some delay where we are waiting for the answers, but it's better than implementing some solution based on the incorrect assumptions.
As you said, a better way to handle this situation would have been to release the last parts of the project after my vacations. At least I learned a good lesson from that unpleasant moment of my career. We can't rewrite the past, but we can use it to write a better present.
For the meetings part, you are absolutely right! It's completely fine to disagree with things, as long as the disagreement is backed by arguments based on facts and "cold" statements, and where it is used to move toward a better solution overall. Though it's easy to let emotions take over in some cases, so it's very important to be self-aware of that, and to avoid these situations (1:1s are there to release the pressure and talk about these issues).
The last part is one of the most important things to do as a developer: learning! I am lucky that I was always able to take time to learn while working. Since it's something I've always done, I felt like it didn't fit the "wish I had done earlier" or "I had done differently" parts. It's definitely something that fits a "I have always done, and will continue doing" article/section though!
Another way to put it: "Always question your own assumptions."
Thank you for sharing your experience. It was very interesting and practical.
For weeklywork logs, do you also take daily work logs to help refer back to and organize them at the end of the week? What about daily work logs over weekly?
Hello! I only maintain a weekly log that I fill every Friday afternoon. I believe writing weekly instead of daily helps me avoid keeping track of trivial/small tasks. For the record, in 2022 and 2023, I have on average 10-12 bullet points for each month. I'm not saying it's a recommendation, but it is what works for me.
That said, if you feel like a daily log can help you write the weekly log, then go ahead! I can only encourage you to do what works best for you :) just be mindful of the amount of details/small things that you write in the daily log. In my experience, not everything is worth keeping in the long run ;)
thank you for sharing extremely useful experiences, i learn so much from your article
So much great advice here! I can definitely recommend being on call if you want to get good at problem solving. Wish I'd started a work log 10 years ago though!
Thanks for the advice sir. I'm a newbie developer currently learning JavaScript.
Thank you so much for the wonderful case study and experience!
I can use it as a learn and reflect on myself and plan to become a more senior role.
Thank you for reading, I'm glad it can help you! :)
1 sentence in and this is absolutely golden
One thing I learned during my over 20 year career in the field is to not rely on the test to evaluate the correctness of the code. As counter intuitive as it seems they are only a tool as many to improve the quality of your code and in no case is a certification of correctness.
The test themselves are "atomic" logic problem that are developed by someone and could vary in their quality. I think everybody had experienced soon or later to have found that unit test that actually did not fail when instead it should, or when someone commited a unit test that actually covered 100% of the code but omitted the result verification of all the involved data (that actually returned the wrong result, or persisted the data wrongly or not at all).
Unfortunately is not easy to catch everything during a code review, and as is not easy on the feature code, it's not easier in the relative tests that can be order of magnitude more complex of the code they are going to test.
So when I've read you left for holiday after realising this big chunk of refactoring because you were confident thanks to the test, I thought "oh boy, this guy will learn an hard lesson". In you case the test where technically all correct, the issue was the most common one pitfall, the interpretation of the requirements or the assumptions related to it. Not well written code and tests can cover you from that.
So yeah no merge before holidays, and hands on deck the first days to iron out the issues that will arise when the code run for real.
Your Haskell engineer should have insight with the utilization of Haskell and ideally other useful programming dialects. Having experience across different dialects, for example, Scala will assist them with guaranteeing that they will actually want to convey what you really want.
They ought to likewise have the option to show insight with conveying projects like your own utilizing Haskell. The more tasks associated with the better as they will actually want to carry that figuring out how to assist with your undertakings>> Mobilunity
The best cheap assignment writing services strike a balance between affordability and quality. Look for providers that offer reasonable rates while maintaining high standards of work, check geekandnerd.org/. By reading reviews, comparing prices, and assessing the expertise of their writers, you can find reliable services that offer exceptional assignments at a price that suits your budget.
This is the most authentic and very relatable article i have read on Career Advice. Thank you so much for writing this, it's so inspiring.
Thank you for sharing so useful content :)
I would love to read about hard skills as well
I'm junior for seven years. If you ask how much I paid and respectable.
I do everything. I destroyed even more health. I plan to get a disability pension and work as a hobby. 😁