Timo Zimmermann - screaming at my screen https://screamingatmyscreen.com/ Timo Zimmermann about software development, leading engineering teams and startups en-en Timo Zimmermann Tue, 15 May 2018 21:19:44 +0200 Taking back control of my digital life http://screamingatmyscreen.com/2018/5/taking-back-control-of-my-digital-life/ http://screamingatmyscreen.com/2018/5/taking-back-control-of-my-digital-life/ <p>I am in the process of taking back control over my digital life. This may be long overdue if you ask some people, while others will scratch their head and hand me a tinfoil hat. Doing this involves self hosting important infrastructure, minimising reliance on third party services and making sure I own the content I actually care about. While content ownership is a pretty interesting topic on itself that deserves its own article, I want to talk a bit about the technical aspects of self hosting data, reducing reliance on the cloud and the actual benefits. <!--MORE--></p> <p>Taking back control is a process of one RaspberryPi at a time right now. <img src="https://share.screamingatmyscreen.com/mounted-pis-res.jpg" alt="mounted PIs" /> Over the last two weeks I deployed three new ones in my basement rack. The first one is taking care of code hosting using Gitea and doing some light automation and continuous integration with LeeroyCI. Sadly the poor, little ARM chip is pushed beyond its comfort zone with running tests and builds for larger projects, so most of this work is done on the "big server". Another one is taking care of home automation, basically running homebridge to integrate weather, wake on lan and other services into our HomeKit setup. It is fully decoupled from the cloud, so the smart home is a little bit less of an tire fire than you would expect. The last Pi is running some communication and notification tools, IRC, Synapse for Matrix / Riot and a service I can send a message to via HTTP and get it pushed to my mobile devices.</p> <p>There is a small NAS with a few disks hosting all data we own. There are two external drives rotated once a week to backup the really important data like business and tax documents. My wife being a digital media artist accumulates quite a few files and we are in the process of transitioning all optical disks to files we can actually watch hassle-free. The NAS also works as kind of "synchronise all" host for Resilio, so we have some kind of central file seeding even if all other hosts are offline. Resilio is one of those strange tools that take you hours or days to fully understand and from there you are fully sold. Initially you have to wrap your head around how it works, but after that it is quite nice to use. Except the fact that they messed up the systray icon on OSX and the color is wrong. <img src="https://share.screamingatmyscreen.com/resilio-systray.png" alt="resilio systray" /> And, of course, it is the primary TimeMachine target. I think the only thing I would like to have automated but have not yet is getting photos from our phones on the server, right now they still go through iCloud.</p> <p>Accessing all of this when I am on the road is actually not a big problem thanks to a working VPN connection and a static IP. A nice side effect of always being connected to my private network is that I always have DNS based ad-blocking, which makes the whole Internet a better place.</p> <p>You would be shocked how fast things can be. We have an Internet connection some startups in San Francisco would kill for, but our LAN beats it every day. 40 Xeon cores, 64GB memory and an SSD raid are faster than most cloud servers you are willing to pay for, so even resource intensive workloads are handled in a very reasonable time. <img src="https://share.screamingatmyscreen.com/server-rack-res.jpg" alt="rack" /> Having work related infrastructure in house, even if it requires some maintenance is in my opinion worth it if you use it on a daily basis.</p> <p>Now that we talked about the infrastructure aspects, let me address the second part a little bit - content ownership. When you would ask me what my highest priority is when choosing software, I will say "usability" in nearly all cases. There are surely a few edge cases where performance, platform compatibility and other factors become more important, but those scenarios are really rare. For my online presence this basically means: Blogging on Medium or Wordpress, shorter content goes to Twitter, photos go to Instagram and Facebook, screenshots to DeviantArt.</p> <p>I am sure this setup would work perfectly fine, but with each platform I lose ownership and control of my content. As you are surely aware you build an online portfolio and persona with everything you publish - as long as you link it to your name. Having third parties involved means the more you rely on your online persona, the more you are at their mercy. What if they decide to terminate your account? What if you article on how to setup Docker is accompanied by advertisement for adult entertainment, or worse, Windows ME?</p> <p>A personal problem with all of the platforms I listed is the fact that even if I am okay with the platform providers collecting, analyzing and selling my data, this is not necessarily true for consumers of my content. Owning as much as possible of the infrastructure and software means I can minimize data collection as much as possible. I do not really care about how many pages a visitor looks at when reading my blog. There is hardly any value, if any at all, for me to get out of click tracking. And I definitely do not need inspiration on what to buy next on Amazon by looking at your purchase and search history, I already got a too long shopping list.</p> <p>As long as I can remember I never used a hosted service for my online presence, be it a portfolio or my blog - the one exception being Tumblr. When I moved to a static site hosted on S3 and lost the ability for quick updates I initially posted smaller notes, just a few sentences, maybe a photo, I wanted to share on Tumblr. The comfort of an always available web interface without the fear of CDN invalidations breaking or the site not being properly generated due to an formatting error was very welcome. But at some point those notes moved to Twitter and photos to Instagram. I am not really a big fan of the latter and the former tries everything to make themselves as unattractive as possible. So here is my genius three step plan, partly executed already.</p> <ul> <li>own media uploads - I use Dropshare to quickly upload media from all devices to S3</li> <li>create a subdomain or directory on this domain for some kind of microblog</li> <li>setup a repository with CI for deployment for the microblog - at least for now that is a sufficient amount of comfort</li> </ul> <p>You may now be asking if all the work to get those things setup, configured and maintained is worth it. To me, yes. Having a lot of the drivers of my daily work in house provides a direct improvement in usability and performance. Getting my work done easier and, or faster is simply a huge win. Owning my online persona is simply getting more and more important for me, as it should for a lot of people who do not really care about it or think about it yet. While it adds a bit work, after the initial setup, to the monthly todo list, I would encourage you to give it a shot.</p> Tue, 15 May 2018 21:30:00 +0200 Choosing the right programming language http://screamingatmyscreen.com/2017/7/choosing-the-right-programming-language/ http://screamingatmyscreen.com/2017/7/choosing-the-right-programming-language/ <p>One of the questions I am asked most often when it comes to programming languages is something that boils down to “should I use X over Y to achieve programming nirvana”. If you believe language evangelists, you would think so. You can make lots of good points to use X over Y or X in general. And maybe even the downsides are mentioned at some point to make it look like an not so opinionated comparison. The question remains - when should you pick which language for your next project? <!--MORE--></p> <p>I am trying to look at this form the point of view of someone getting into programming or already being into it and planning to work on a new side project. While some of the arguments hold up well in a business or team environment, some of them get less relevant or eventually completely change if we have an already existing codebase.</p> <p>I do not believe it is a secret that I really enjoy Golang and Swift. Maybe even that I had a hard time with Python and its community the last few years. In the business world I feel ambivalent about Java, for side projects I still see the arguments made in a business setting but I would not touch it if not absolutely necessary.</p> <p>Based on this it sounds like I would most likely start new projects in Golang or Swift. Especially considering Swift is the new, overly hyped newcomer in web development and it could be fun to actually ship a web service or app written in Swift - also, I will most likely do this at some point. And still, I created a virtual environment using Python 3 and installed Django when starting a new project I actually want to get live soon-ish.</p> <p>Why should I not have used Python and Django?</p> <ul> <li>it is slower than the alternatives</li> <li>deployment is a lot harder</li> <li>it lacks a few things I appreciate in a language like static typing (no, type annotations are not a sufficient replacement, even if they are a decent band aid)</li> <li>for anything outside of the CRUD world Django simply gets in your way</li> </ul> <p>Only to name a few points. But still, why did I start a new project using this old, slow and definitely lacking technology?</p> <ul> <li>it works. There are no surprises and there are battle tested libraries for everything you need - read: DO NOT ROLL YOUR OWN AUTH</li> <li>some of the problems only need to be solved once, so over the lifetime of the project they can be neglected</li> <li>nearly no project will get to the stage where one or two app servers cannot handle the load. If they do: you got more important problems to solve than adding a third server. But performance and scalability are far less relevant than benchmarks make you believe.</li> </ul> <p>The “do not roll your own auth” part is my favourite one to explain my point about battle tested third party libraries. To roll your own auth you also need to solve proper password hashing. Also session creation and termination. And resetting passwords. And and and,… there is a lot related to this. We are talking about one of the areas in a web app that can make your project the headlines of some random tech blogs telling everyone that you lost user data. You literally cannot mess that part up without jeopardising your whole apps security.</p> <p>I am not saying you should never do this. Once you understood the concepts implementing basic functionality is pretty straight forward - while writing this I notice I should increase my blog draft directory by one more explaining how to do this - but it still consumes quite a bit of time, work and you have to rely on a few third party libraries, like one to hash passwords, which are hopefully properly vetted and tested.</p> <p>Golang libraries for authentication, for example, do not even come close to Djangos or Flasks packages, even after roughly 6 years or so and quite a few attempts by really smart devs. They do some of the things you need. Sometimes even in a way that you could theoretically integrate them with enough work. But they never get you the same comfort, luxury and safety as the ones in the Python world. The same goes for templating. Admin interfaces. ORMs. The list goes on.</p> <p>There are certainly situations that strongly suggest choosing one language over another. Sometimes there are specialised languages, like R, sometimes there are simply natural fits like writing iOS and macOS applications. But strictly looking at general purpose language for web application development it simply comes down to one question: Do you want to get a product done or do you want to play around with a language and maybe create something as a side effect.</p> <p>If you are set out to create a product use whatever you are comfortable with or what seems the easiest for you to learn when just starting to get into programming. It is 2017. Servers are cheap. Scaling to a certain point is a well understood and solved problem. And getting started with something that is not quite the right fit is better than thinking about languages for dozens of weeks and not getting any real work done.</p> Tue, 25 Jul 2017 19:25:00 +0200 A Series for newbies http://screamingatmyscreen.com/2017/7/a-series-for-newbies/ http://screamingatmyscreen.com/2017/7/a-series-for-newbies/ <p>I receive a few questions via email or Twitter over and over again - looks like people take my footer seriously. <a href="https://twitter.com/sehurlburt/status/889004724669661184">Stephanie</a> advocates helping newbies in the industry or who want to join by offering mentoring, which is something I fully support. As a lazy engineer I thought writing answers to the most common questions down saves time in the long run but also helps transfer knowledge to people who do not directly want to ask for mentoring. <!--MORE--></p> <p>I feel like I should add a small disclaimer that I am using the term "newbie" as it was initially intended - to describe someone new to something and other than in some places not judgmental or in a derogatory way.</p> <p>If you think I should cover something specific please let me know on Twitter or send me an email.</p> <p>When you are reading this I should already have published a first take on programming language selection. I will also try to keep this post up to date with links to all published articles, as well as tagging them all with the "newbie" tag. A better way to stay up to date would be subscribing to the RSS feed tough - I know, ancient stuff, but still the best we got as long as JSON feed is not widely adopted.</p> Tue, 25 Jul 2017 19:22:00 +0200 Static site generator burnout http://screamingatmyscreen.com/2017/1/static-site-generator-burnout/ http://screamingatmyscreen.com/2017/1/static-site-generator-burnout/ <p>I think by now it is not a secret anymore that I am a strong advocate of static site generators. Especially combined with some CDN making all your security and scalability concerns go away. When asked which one I recommend I usually throw out the two most used ones, <a href="https://jekyllrb.com">Jekyll</a> and <a href="https://gohugo.io">Hugo</a> and also sneak in my own, <a href="https://github.com/fallenhitokiri/drupan">drupan</a>, with the disclaimer that it is opinionated, but still proved to work quite well for different projects. Last year I did not really blog much, but I wrote a few posts. I did not really work that much on drupan, but there are new commits and a 2.4 release pending. What happened?</p> <!--MORE--> <p>There are several reasons, not getting much work done was basically a result of a nearly 5 month crunch time at the beginning of the year followed up with even more stuff to do. I simply had to recuperate, gather some strength and inspiration, take a bit time off and code less. But during the whole time one of the things I planned to do first, once I am back in the game, was taking care of my blog.</p> <h2>Editing is a pain - I miss a CMS</h2> <p>I think by now we all know the advantages of static site generators, writing in markdown, having everything in version control,... Count me in on that. But writing markdown and writing blog posts are two different things. Blog posts have links, images, maybe a video? Manually copying around file names and URLs, hoping you got it right till you generate the site is annoying. Manually managing your files is even more annoying.</p> <p>I simply miss a proper CMS. I was certain I will fix this with Sakebowl, but I am not that sure anymore. Having a flexible CMS that plays nicely with a static site generator is certainly possible. There are a few out there, some of which barely made it out of toy stage and some are actually usable, but far behind of a modern CMS.</p> <p>This is a solvable problem, it is just not properly solved yet. This is also one of the reasons why I did not publish a lot last year.</p> <h3>Multi-user workflow</h3> <p>Do not get me started on this mess. Write a file, send it to someone to review and edit, get it back, replace it, read it again to make sure the edits are correct and hopefully publish your article.</p> <p>There are a few workarounds like keeping your whole site in a version control system and using a hosted service which allows editing files. This partly solves the problem and is not the worst idea. But it is also far from comfortable.</p> <p>It also messes up your workflow to a certain degree. Right now I write most of my articles in Ulysses. After I am done I have to export them to a markdown file, drop to the command line, commit and push, send the link or review request to my fiancee, pull and build. Sure, it is doable, but to me it still sucks. If I would tell myself 10 years ago that at some point I will consider this an unacceptable workflow I am sure I would have declared my future self crazy.</p> <p>Purely working in some online VCS hosting platform is also not really an option. Forcing people out of the applications they started using for some reason is, most of the time, a fight you will not win. Especially when it comes down to something where personal preferences are important, like an editor.</p> <h2>CDNs aka “love hate relationship”</h2> <p>Content delivery networks are, at least in my opinion, one of the best things that ever happened. Having files across the globe, highly available, served as fast as most consumer Internet connections allow for a stupidly low price? Sure, sign me up! And thanks to the fact that we are living in 2017 you can get SSL for free! Even better. How could anyone complain about this?! Well, believe me, I can.</p> <p>So here is what usually happens: I write a blog post, get the editing mess done and publish it. But wait, it is not really published yet, it is only uploaded to S3. The Cloudfront invalidation will take five to ten minutes before it is properly published to all my readers. Sure, I could lower the TTL and skip invalidation requests, but that still means sitting around for some time. Or I could make it so low, that most likely every of the 1000 requests from users a day result in an cache miss making the request slower. For some reason I get a lot of bots hitting my site, but not distributed enough to keep the cache warm.</p> <p>Now we could argue that this is kind of acceptable when you publish something. It does not happen that often, does it? But what about edits? When publishing a post it is possible that it is submitted to HackerNews or Reddit. Want to add a link? No problem, but readers will have to wait for the TTL, most likely resulting in some who would be interested missing the links or for the invalidation request to finish, most likely a lot worse.</p> <p>This does not mean hosting your content on a CDN is a bad idea, it simply means that sometimes I want to update something in real time.</p> <h2>New features</h2> <p>There is a certain set of new features I want to add to my blog. A few of them will be a matter of minutes, like adding a new category for short notes I use to post more frequently instead of splitting text on Twitter for example. But there are things, even with a proper CMS backend, which are somewhere between hard to achieve or greatly increase the backend complexity.</p> <h3>Subscribe to blog</h3> <p>I want my readers to be able to subscribe via email. Sounds simple, doesn’t it? If you have a purely static site the best option will most likely be using a third party service like mailchimp and manually sending out a mail or somehow integrating it as plugin in your static site generator. Since the URL for your content is known before you publish the site, even if your index and archive is not yet up to date thanks to the CDN, you can trigger a mail pointing directly to the post.</p> <p>Of course, this would require the use of client side JavaScript. If this is acceptable in 2017 or not is something everyone has to decide for themselves and the answer is most likely tied to the target audience. One thing that is often ignored is that this is a third party you give your readers data to.</p> <h3>Post via email</h3> <p>Fancy, isn’t it? I want to sit on a beach in San Francisco - hey, I am allowed to have a weekend, even on a work related trip! - and post a picture. Partly to annoy my friends back at home suffering through 8°F days or to inform others that I am currently in SF, which automatically means I am up for a coffee or beer. Don’t ask why, but this sometimes works better than sending a tweet or email.</p> <p>Sure, I could login to a web interface, if I had one, and use this to post. This would even be acceptable, but sending an email is faster. Also I like email. It is one of the few things that never messed up badly during the last 20 years.</p> <p>Actually posting from anywhere, even if it would involve a web interface, would already be a big step into the right direction.</p> <h3>Queues, workers, complexity</h3> <p>Drupan is written in Python. And Sakebowl, the backend, is partly written - as in started but not finished - in Python and Django. Adding new features nearly always requires having a queue, even as simple as Redis, and having workers running doing the heavy lifting. Simple enough, isn’t it? Especially because those are things I am dealing with on a daily basis for over 12 years by now.</p> <p>But something in me is telling me it is not worth it. Having all those different things running, making sure they are available, come up on restarts, handling errors - it is some complexity I am not sure I am willing to maintain in my spare time only to publish a few articles.</p> <h2>Alternatives</h2> <p>There are currently no alternatives I would be satisfied with. I will never move my content to a third party platform like Medium. I will not start messing around with some stale Node.js abomination that consumed an insane amount of crowd funding money for no apparent reason. But I am also not sure Sakebowl will be the right call.</p> <p>Currently I am considering moving from a static site generator to a more mainstream CMS or blogging software. I am not too worried about uptime to be honest. Nearly all hosting providers I have dealt with during the last 5 or 6 years rarely have any downtime and if they do it is a matter of minutes. I actually had more downtime on AWS (admittingly not S3 or CF!) in 2014 if I recall correctly than on my Hetzner vserver. Sure, different beast, but you get the point.</p> <p>I am also not too worried about content being linked on some popular site resulting in a spike in requests. Having the site or page cached in memory should not be hard for any serious blogging platform. And it will most likely be “good enough”.</p> <p>But I still have this point somewhere in the back of my mind. A blog going down because it makes it to the frontpage of HackerNews is just lame. It would still possible to put a CDN in front of whatever, so this should not turn into a problem, but this also would not be much of an improvement to the current setup.</p> <p>Security is a tough cookie. I do not believe any system can beat the current S3 + CloudFront setup. But at the same time I believe it is possible to get a system secure enough that, while not directly targeted, it will survive the big, bad Internet. If directly targeted, well, it is most likely game over. If this turns out to be a major problem it is something I cannot predict.</p> <p>I would prefer having a simple setup. Installing an interpreter, a database, a key value store, a webserver, messing with some obscure startup script to get application servers and workers running is something I would love to avoid doing in my free time.</p> <h2>Are static site generators a bad idea?</h2> <p>Sure, that would make a great headline and most likely guarantee a heated discussion, but sorry to disappoint you. They are as good, or bad, as they always were. I am simply looking for features which are not that easily realisable using a static site generator and which are maybe also not that well realised with an backend for one.</p> <p>I believe static site generators are definitely the right choice for anything that is not updated frequently and has a technical editor. You can even make it simple enough to make copy changes - GitHub + some CI and you are good. Not that comfortable, maybe a small fight against existing tools, but you could manage to get away with it. Agencies maintaining websites for customers? Definitely! Chances are pretty low that your friendly doctor needs any dynamic elements on the website, at least in most parts of the world. Marketing site for a SaaS business? Yep. Decoupling your marketing site from your actual app is not the worst idea.</p> <p>I still love drupan and I am actively working on it. But for the things I want it seems to be a bad fit for it - this is actually harder to admit than it should be. I am currently not sure what the correct solution will be, but I am actively working on it.</p> Mon, 23 Jan 2017 18:39:00 +0200 Surviving Crunch Time http://screamingatmyscreen.com/2016/7/surviving-crunch-time/ http://screamingatmyscreen.com/2016/7/surviving-crunch-time/ <p>For the first 4 months this year I was in a constant crunch mode. At FlightCar we usually tried to avoid this, but we had to ship a redesign of the website, a redesign of the iOS app and finally release a customer app on Android. As for most other seasoned developers this is not the first time I experienced such a time and it will likely not be the last. Over the years I developed quite a few strategies to handle crunch time (and stay sane and productive at the same time) I want to share with you today. <!--MORE--></p> <p>The best case, of course, is to avoid crunch time. Some companies, especially Start Ups claim that this is not possible and that you have to be in a constant crunch. Here is the secret they do not notice most of the time: Playing table soccer does not count as work, no matter how often you try to tell yourself you are working for 25 hours a day while you are actually only shifting the location of your free time. Browsing HackerNews and reddit mostly also does not count as work, sorry.</p> <p>If you still find yourself in a constant crunch one of those two things most likely happened:</p> <ol> <li>You have no idea how to create a proper roadmap</li> <li>You have unrealistic expectations</li> </ol> <p>It usually boils down to one of those two options. One thing you have to realise is that you’re either making sure your developers burn out and you have to hire new ones every three to six months – or you are not actually in a crunch but decided that your free time should be spent in the office doing everything but work.</p> <p>As I already admitted crunch time can happen and there are various, legit reason why it happens. And most of the time it is something that will decide the future of the company. Now if it happens the trick is to make sure you, the team and the companies actually survive crunch time without going crazy, burning out or setting tables on fire.</p> <h2>Daily Routine - Stay Healthy</h2> <p>Even if most of your day is spent working, there are a few things I would strongly suggest doing on a regular basis, first to stay healthy, second to refresh your body and mind.</p> <ol> <li><strong>Exercise</strong> - even if it is only a 10-15 minutes walk, do something that forces your body to move and try to not think about work.</li> <li><strong>Sleep</strong> - no, not with your nose leaning against your screen. In a bed. For more than 5 hours.</li> <li><strong>Eat</strong> - a proper diet, not pizza and Jolt Cola mixed with energy drinks and ibuprofen.</li> </ol> <p>The exercise part can be a bit controversial for some people. I will not try to look up all the studies that actually explain how important this is since I am not in a position to actually verify them, simply take it as a suggestion. It helps me a lot to stick to my daily exercise routine, give it a shot!</p> <h2>Your Team</h2> <p>A project which decides the future of the company also means that during crunch time a lot of people will have an eye on the product and regularly check if the team is on track to get it done. After some time in the industry you will get used to C-level executives looking over your shoulder when you work on something important - and they will remind you how important it is. In itself this is not a bad thing, it only shows that they care, which is actually awesome! Far better than the opposite when they simply stopped caring about the product.</p> <p>There will sometimes be people on your team who are not used to management having such a close eye on what they do, the expectations to get twice the work done in half the time or working on something that could kill the company if something goes wrong. Keep an eye out for those people and try to help them as much as possible with advice and guidance. This should actually be always the case, but someone being a bit stressed during a regular 9 to 5 day is far less likely to go insane and it is way easier to counter than someone not sleeping for 5 days straight because the only thing they got in their head is “if it fails, everything is over”.</p> <p>While you usually cannot downplay the importance of a project, you can set the expectations straight that not getting everything 100% right in time is most likely not as bad as it is suggested. The fine line between motivating a team and putting so much pressure on them that they break is hard to hit. When in doubt try to not get too close to it.</p> <h2>Manage Expectations</h2> <p>You will usually have one big goal at the end of crunch time. Maybe it is a redesign, maybe it is a new feature, maybe it is a new application. But the goal will be defined fairly broad and a lot of smaller components are needed to make it happen. Not all of them are necessary to deliver a great product or a stripped down MVP and not all of them provide the same value to the customer.</p> <p>It is important to start managing expectations early on. Make sure you have all components on a list ordered by priority. Does your admin interface have to be redesigned as well and launched at the same time as the marketing site? Most likely not. Would it be great if your iOS and Android app have feature parity? Sure, but if the app is only supporting your business and is not the core value, it could be sufficient to focus on the core features which are most important for the customer.</p> <p>While product, management and all the people involved can tell you what they ultimately want, only you can tell them if this is realistic, which tradeoffs could help to make it happen and how fast after the expected deadline you can deliver the missing pieces. Start this conversation early, best before the actual crunch time starts and make sure everyone knows and agrees.</p> <h2>Shortcuts And Cleaning Up</h2> <p>“We are going to write the most beautiful, well tested, stable code the world has ever seen” - no one ever during crunch time.</p> <p>You will be taking shortcuts. No matter how good your intentions are. And the shortcuts will be shorter and more ugly than the ones you are usually willing to accept. This is okay, crunch time is not about writing the best code in existence. But, no matter what shortcuts you take, it is important that the product is working as expected. Shipping something broken never helped anyone, and shipping something broken in time is in my opinion worse than not shipping at all.</p> <p>What I strongly suggest is planning time after crunch time to clean up, refactor and make sure your working code is stable and maintainable. Leave some comments in there to identify the parts where you willingly took shortcuts. While most people have the intention to do this, it does not always happen. Making sure this actually does happen is part of the management responsibility for crunch time, the same as setting expectations properly. If you miss this, you will end up with a system that is holding together for now but blows up in a few weeks or months. That this will be required should be communicated to all relevant people before crunch time starts and you should make sure they agree to give you the time. While this is no guarantee, it increases the likelihood to happen.</p> <h2>Final Words</h2> <p>This surely sounds pretty easy and straight forward. Sadly it will not be that way. People will be stressed and as you probably know it is not always easy to work with stressed people. If you got a partner you should make sure they understand why this is so important and if you are lucky they are understanding. When it is over make sure to compensate for the lost time of your life. Always remember that your health is the most valuable thing you possess. Crunch time sucks, but you cannot always avoid it, try to survive the best possible way.</p> Fri, 22 Jul 2016 19:00:00 +0200