Also: give yourself a reason to stop working in the evening. I almost naturally developed routines at the start and end of my workday: - Alarm rings every workday at same time

- Might slack a little off on Social media, then get up

- Get dressed appropriately for video calls

- Make breakfast, coffee, grab a bottle of water

- Take those things into Home office, start working

- Work throughout the day, get up from time to time to get coffe, water, have lunch, maybe throw some laundry into the washing machine - however, not more chores during that time!

- When it's time to stop working, close all programs, put Laptop to sleep or turn it off, turn of external monitor

- Get out of the home office

- Immediately after stopping to work, either do some chores or hit a workout (Reason to stop!)

- Done. Mind is off of work. Have dinner and/or do whatever is planned for other free time

EDIT: Formatting, wording

2. Smart Home stuff like turning on the light on sunset if I’m home, turning off the lights when I leave home and multifunctional wake up calls using light and music.

3. And which I guess I’m most proud of: I’m secretary at my local volunteer fire brigade and one of the chores is to send out a weekly email to everyone with a digest of trainings and other appointments in the next week. To get this out of my head, I wrote a serverless function that queries a special google calendar for this, collects titles, start times and notes, generates an email and sends it out to our members. This lets me just manage the appointments within my calendar and takes care of all the mechanics. Fun fact: this works that good that sometimes people come to me with “yeah, about your email...” and I’m like “which E-... OH!”

4. Vacuuming. My roomba has paid for itself several times with the time it’s saving me

1. you have to transport all this stuff. Fire trucks have a notorious tendency to be overloaded and all these stable hoses and jets additionally take a lot of space on the truck (which is also rare)

2. Assembly (and maybe operation) seems to be kind of complicated. When being under adrenaline and pressure to quickly save people and buildings/goods, that is very counter-productive

3. Firefighting techniques try to evolve into using water as effective as possible, this does not seem the case here. Apart from being an environmental and infrastructural issue (e.g. pressure surges bursting water pipes and/or connectors and simply using up the available water supplies), water damage on building is often higher and more problematic than the damage done by the actual fire and smoke, so it is key to just use only as much water as neccessary to extinguish a fire, especially inside of buildings. I don't think flying your equipment on water jets towards the fire will help with that :-)

I see this as the first baby steps to where things will ultimately end up. This may not be the exact tech, but it's a start.

Also for fighting fires inside buildings I think there may be scenarios where robots can bring advantages and safety to firefighters. However, in most of these cases the primary objective is not to extinguish the fire but to search and rescue for people still missing in there. This is often a task an order of magnitude more difficult, especially for machines (we have problems detecting moving people on open roads, try that with unconcious people in a room filled with smoke and fallen over funiture and items - neither normal nor IR cameras will tell you the whole truth. This is even very hard for people), so your mileage will vary from mission to mission. I don't have a problem with the idea of using robots for this, in contraire, I would like to have the opportunity more often, I would however have them in a different form factor - more the mars rover kind or what we have seen from boston dynamics, with flexible hoses that are better to store and maneuver in small spaces. Also, as I said, using water for propelling will do a lot of damage we are actively trying to avoid.

EDIT: Mainly because of that there is also much work done from the inside, with fully independend respirators and heavy heat gear. A few decades ago, you used to say "spray in on top until the water coming out on the bottom is cold", however the damage is then about as big as if you just would have let the house burn down, so with getting more high tech materials, everything started switching towards more precise actions using less water, often even deconstructing the parts of the house affected by the fire (e.g. had a mission last week where we were ripping apart the roof insulation and opening spots in the roof of a house in a fire after lightning strike, only applying water to the really burning parts).

I would like to see a progress towards a way of working as you mentioned it, but I'm not sure if we would end up exactly there. On a site, there is so much going on that I don't think one person could handle a whole mission remotely. More of a smaller team going out, handling the dangerous stuff from a safe distance very effectively through specialized robots. Firefighting is also a lot about giving the affected people the feeling that someone is there for them and rebuilding their feeling of safety, handling everything fully remote might not be helpful with that.

20 years ago the tech we have today was science fiction. The idea that every person on the planet could have a multi-camera internet connected device would have been ludicrous.

But I understand your perspective, you seem to actually at the sites where you can see how hard it would be for a robot to achieve the same results as a human. But isn't the hope (for geeks anyways) of the future of tech that robots will be able to save _more_ lives than humans alone?

Also, there's a fire fighting game that got popular a few years back. If this is a harbinger of things to come, firefighters in the future may be using xbox controllers to fight fires, just like they use them to fly drones in war.

Also, on the other hand not being able to recognize that your car is about to slam into a stopped emergency vehicle is also a giant gaping flaw on the driver's side.

Disclaimer to put my last statement into perspective: I have absolutely no relation to Tesla except for being a potential future customer. However I am driving a decent stretch daily and get to experience first person many stupid things people do in their cars due to ignorance/not paying attention/whatever, also I often use the adaptive cruise control of my Audi which shows me quite some false positives and restrictions (such as not letting itself deactivate below 15mph, heck, even deactivating itself without previous notification)

I don't understand your logic. Stationary objects either are rare, and wouldn't trigger too many false positives, or they aren't, and the car should be prepared for them.

I saw a tv program about self-driving cars a couple of years ago where the programmers said they would have it ready for major roads in a couple of years, but their human factors engineer said "a couple of decades", precisely because they realised humans would always be needed, and that the problem of transferring control back to humans while riding on the road hadn't been solved.

What always boggles me about such news is that people rely so much on these systems and apparently people drift away that they even don't notice an f*ing big red fire truck standing in their way. I often drive with dynamic cruise control (radar based, only keeping distance, breaking and speeding up, no steering), but I am in many situations in which I think "I need full control here" and temporarily disable it. Also, there are many situations where I don't use it in the first place because I know the way it functions is bringing downsides, such as driving on multi-lane roads (read: german Autobahn) since it will hold exactly that much distance to the car infront of me that every idiot will cut in, causing cruise control to decelerate to leave a bigger gap, rinse, repeat.

Maybe you're not a typical case?

FWIW, I consider myself a pretty decent focussed driver, yet when I hired a car with dynamic cruise control a few months back, I was shocked how much losing responsibility for part of the driving experience --the gears, acceleration, and braking, obvs-- helped me to relax too much, and lose a little bit of focus. I was still steering, and it wasn't like there were even any near misses... but I just felt my attention wander too many times for comfort.

Of course, I also notice that my focus changes a bit, but it still stays on the traffic around me and I would consider it rather improbable that I would oversee a stopped vehicle infront of me, not to mention a fire truck on a mission.

Maybe it's also that I'm driving daily in and out of Stuttgart, one of the main traffic spots in southern Germany. There's a lot of cars and ignorant driving, especially in dense traffic or jams. Plus we have a rediculous amount of roundabouts in the meantime and there are a lot of people that decide to either push into the smalles gaps, shooting in from your side and forcing you to do heavy breaking or other people approaching an empty roundabout, doing a needles near-full stop, accelerate, just to decellerate again, almost coming to another near-full stop to get around the corner (never understand the thinking behind this :-| ). I don't trust adaptive cruise control in either of these situations.

We are searching support for our data services engineering team. Störk-Tronic is a middle size company that is well established in the market of temperature controllers for a wide range of different industrial usecases ranging from cooling systems for medical appliances to ovens.

Improving connectivity and remote management and analysis of our products has much focus, so we are searching for Embedded Linux Developers as well as Web/Frontend and Backend engineers to work on our cloud platform (based on AWS, Docker, Kubernetes, Java, JavaScript and ReactJS).

For more info, see http://stoerk-tronic.com/de/karriere.html (german).

In a more general view, having skilled peer developers that have extensive knowledge in the field I am working on and are willing to mentor. I did my BS in a dual system that consisted of half a semester studying and the other half working in different teams of a software company with ~150 devs. During this time I had two or three very good mentors who not only made sure I am doing the right thing but also showed me how to do them correctly. This meant mainly reviewing the architecture and code I came up with and telling me when I was doing bad practice and how I should do properly. I think the situations I learned most in my whole studies were when one of these mentors refused a review or help me some higher level problems until the flaws they found in my code weren't fixed. This made me develop a feeling about if the approach I'm taking might be a bad idea and what to do instead that I can most often trust to a certain degree.

The other thing is to go beyond the basic tutorial steps for advanced technology like datastores, queueing systems and such. To me, this works best when I have the option for using them for a certain case that is (or will be) more or less important for production. I think gaining brief information about different frameworks etc. without wasting too much time before you need them is very important to know your options but you only fully understand the characteristics and problems behind them once you put them to an extensive and got hit by their pitfalls.

#1 is in my dayjob:

We use docker in combination with vagrant for spinning up a test environment consisting of several containers with different components (both ur own products and 3rd party) to run integration tests against them.

The main reasons for this approach are: - We can supply containers with the installed producs which saves time on automated runs since you don't have to run a setup every time

- We can provide certain customizations which are only needed for testing and which we don't want to ship to customers without doing all the steps needed for that over and over again

- We have exact control and version how the environment looks like.

- Resources are better distributed than in hardware virtualization environments

#2 Is a pet project of mine, a backend for a mobile App. There are still big parts missing, but in the moment it consists of a backend application which exposes a REST API running on equinox plus a database (in an own container).

The reasons I see for using docker here:

- I have control and versioning of the environment

- I can test on my laptop in the same components as prod, but scaled down (by just spinning up the database and one backend container)

- Since more and more cloud providers are supporting Docker (I am currently having an eye on AWS and DigitalOcean, haven't decided yet), switching the provider in the future will be easier compared to having, say a proprietary image or whatever.

- If I ever scale up the poject and onboard new teammembers, the entry barriers for (at least) helping in Ops will be lower than if they have to learn the single technologies until they get at least basic knowledge of the project.