今日推荐开源项目：《GAL Librian》
今日推荐英文原文：《No, You Won’t Get It Done Over the Weekend》
今日推荐开源项目：《GAL Librian》传送门：GitHub链接
推荐理由：相信绝大部分人应该都知道 galgame 是个啥玩意——简单地说，这是一个故事用最简单的方法转换成的游戏，也可以叫它视觉小说，由对话框和人物图像等组成。这个项目则是一个简单的 galgame 引擎，能够简单的制作出视觉小说来，相比起原本的文本小说来说，视觉小说能添加更多功能，当然也能玩的更花（当然这些功能大部分时候都用在了恋爱题材的游戏上），在文字世界里有女朋友，不也挺好吗.jpg。
今日推荐英文原文：《No, You Won’t Get It Done Over the Weekend》作者：Albert Kozłowski
原文链接：https://medium.com/better-programming/no-you-wont-get-it-done-over-the-weekend-1cbfc10eee01
推荐理由：永远留出更充足的时间来工作，因为你永远不知道接下来会有怎样的冒险，会被怎样的非日常卷入——从而导致错过死线
No, You Won’t Get It Done Over the Weekend
Software developers, your free time should not be a buffer
I can’t count how many times in my life (or even in a year) I’ve heard people say: “I will get it done in the evening…”, “I will get it done by Monday morning…”I think every developer (including myself) is guilty of saying something along those lines at least once in their careers. There is no doubt that estimations are hard — it might even be the hardest thing to get done within software development.
That is why it is very important to communicate delay and manage expectations accordingly.
In my opinion, one of the biggest problems when giving an estimate has to do with conflicting expectations between parties.
In general, when a person asks you when the task will be completed, they are not referring to when the actual coding will be done but rather when the task will be deployed to production or when it will at least be at the UAT stage.
There is a massive difference between coding by yourself versus working with a team, which is why this post will be focused on organizations and not necessarily on the workflow of freelancers.
In general, when working with teams, there are extra steps that the code must go through. Including the following:
- Coding
- Unit/functional tests
- Code review
- QA sign off
- UAT
- Deployment to staging & secondary testing
- Deployment to production
From this perspective, even if the coding is in fact done over the weekend, there are plenty of extra steps to be completed before it gets to production.
Keep in mind that your code may be rejected during the code review, and QA might even find a critical bug. It is important to remember that the task is not done until it is done, or should we say until it is in production?
Don’t Get Locked Out
Weekends can also be tricky times to be at work, for a variety of reasons.For starters, your partner, friends, or family might expect you to be available and being constantly at work may take a toll on those relationships. It may also be that you end up having to go shopping, or perhaps that your Friday night might have run longer than expected.
But, even if that is not the case, being by yourself at the office limits the possibilities of troubleshooting technical issues effectively, which may even prevent you from moving forward until Monday.
In the odd case where everything on the tech-side works perfectly, something completely unexpected might happen.
For instance, there was a time when I was working on a very delayed project and one of the developers in the team decided to come to the office over the weekend to catch up on his work.
In that particular office, there was a card access system on each floor. While my colleague was at the office that weekend, he decided to go to a different floor for a moment and ended up leaving his ID behind.
As a result, he got locked out of the office. No flat keys, no laptop, only a phone in his hand.
I don’t remember exactly how he managed to get out but I know that he had to call a few people while at it… I bet he didn’t account for the lost time when he initially set out to complete his tasks.
It’s Hard to Say No
Developers are not entirely at fault for getting trapped in these kinds of situations. Sometimes it is extremely hard to say no to a short deadline.I often feel like dev teams are bullied into giving short estimations by other departments and that forces them to cut back on any buffers that could account for time lost to mistakes and unexpected changes in general.
The truth, however, is that your free time is not a buffer, and it should never be.
Having said so, yes, there are situations when the work needs to get done during the weekend or evenings but that should be an exceptional situation and not the norm. It’s better to give a high estimation, even if it might ruffle some feathers instead of constantly having to catch up.
By promising to work weekends (even when you succeed), you still lose some of your credibility. It ultimately sends a bad message; one that says that the task’ completion times are being underestimated.
Furthermore, a lack of credibility hurts you and your team. It will eventually evolve into a lack of trust, and as we all know, this is something very hard to rebuild.
If you are a junior/mid developer you might feel the pressure to work fast, but it’s better to learn how to manage your work and expectations to avoid using your free time than dealing with the long-term consequences of not doing so.
Deadline estimations should include some buffer time because shit will hit the fan — that’s life. Even when planning thoroughly and including buffers, you might end up running behind schedule.
Instead of committing to work over the weekend, just request extra time. Then if you really want to, you could still use your free time but you should never use it as a default option as others might take it for granted.
In situations like this, I like to remember that time is the most valuable thing you can give to other people and it should be treated accordingly.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
