今日推薦開源項目：《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/
