Here is my experience working remotely for half a year: First thing I'd like to mention, we didn't have much problems with our communication. Skype and Slack were more or less enough to cover this part. Perhaps it's not as good as face-to-face everyday communication, but Scram daily meetings help and if there is something big to discuss we could always call each other anytime. Working remotely gave me a few additional hours a day on average, approximately upto 3 hours and I was happy to spend this time to rest and learn. As long as you have a routine and all the necessary conditions (environment) it can be very efficient. Expenses-wise, time-wise, etc... What I didn't like though is the lack of social communication and additional workload. Those were half a year that felt like a day to me, really. It was fine in the beginning, but several months later even I (an introvert by the way) was really uncomfortable with how little interaction I had with other people and outside world. It starts to creep on you. Little by little, you notice that this routine of 6-7 hours of coding is getting harder with each passing day. Also, if you work in office, pretty much everywhere it's like: Get there, have some tea, a chat with your colleagues. Work some time, have a meeting or two to discuss things. Dinner time, then work a bit more, maybe do a code review or two. Go home. People actually don't work 8 hours straight, they do it in very short burst of productivity with constant breaks. It's not as efficient as coding at home for hours without interruptions, but it's much better in the long run as it decrease a risk of burn out quite a bit.

I do feel this quite often. But that's simply because people I tend to work with are really smart and brilliant software engineers, who have years of experience on me. Then again, people go their different ways when it comes to learning new things. You can't measure everyone by the same universal scale and that's why hiring process is so difficult nowadays.

From what I understand there is basically some open source code that needs a good refactoring here and there and you're not sure whether you should touch it or not. I don't have any experience with open source, to be honest. I'm sure you already know that, but unit tests are your safety net when it comes to refactoring. If there are none, ask yourself whether you're ready to invest time to write good unit tests - which usually takes quite a bit of time. Other then that: sure, why not? It's up to contributors to accept your PR and if they have some reason to reject it, perhaps they will be able to provide some useful feedback as well. Either way, people never learn how to write clean code unless they actually try - you can at least consider it a good exercise. Be ready to meet some resistance along the way. I've never contributed to open source, but people who never read Uncle Bob sometimes don't understand and share same ideas and visions you do. I had colleagues who accepted those ideas, but there were far too many who could not for the life of them understand that function is not simply "reusable piece of code", but first and foremost a "named piece of logic", that can have a damn name longer than its actual body definition.

AFAIK in most companies code review is done whenever a task is ready for it and my current team is not an exception. What differentiates my employer is that there are many cases where you don't really have to pass it unless you really want others to take a look at your code. It depends on several factors: How many people in your team have understanding of that particular part of the system. How many of them are available for code review at the moment. How crucial your changes for the system as a whole from architectural stand-point. But most of the time I still ask others to take a look, unless I know for sure that my colleagues are busy and the code is a bugfix for something I've done myself.

I wish I could say that "Yes I follow TDD" and leave it at that. But since we try to have an honest discussion here and the topic is really interesting for me as well, I feel like some additional information should be provided. First of all, I do try to follow TDD/BDD/(whatever the new shiny word it is now) whenever it's possible. The concept itself is very nice. It's all about systematic approach and being consistent as much as possible even if sometimes it feels like it takes more time to produce satisfying result and sometimes it does take more time. But being consistent is nice and often I find it much easier to develop in this incremental way. Now the "problem" is: we don't have unit tests for every component. Or is it a problem in the first place? Frankly speaking: I have no idea. But the more experience I get the more I find that being dogmatic about something is often not viable approach. A lot of code is written to work with different kinds of data sources (DB, Elastic Search, JMS, etc.) and very often I find it impossible to find time to write unit tests for that kind of integration logic. Not even sure you need unit tests for it, as integration tests would do a better job. Especially if you work with a codebase that changes very quickly, like in a startup environment. It's just that people responsible for the business side of the project always want new features and it's already very difficult to squeeze in something tech-related (e.g. refactoring) as it is. On the other hand, when I feel that logic is worth to be tested and it's possible to do now , within reasonable amount of time, I try to follow TDD cycle. The result is not always as good as I want it to be and it sometimes it does take more time than "tests after" approach and especially "no tests at all" approach. It may be just the lack of experience on my side, really. Perhaps I have yet to understand the brilliance of TDD in it's absolute form or something. But then, I've never even had a chance to work with people who even try this approach, much less encouraged it - there was no one to show me the ropes. At the end of the day, I think that unless your team already follows TDD and has established practices including those for time estimation, it looks impossible for me to follow TDD even 90% of the time.

For me the goal is: get more comfortable with functional programming in Scala to the point where I can use it to solve real problems at work in a (hopefully) better way. Also, they say the mother of learning is repetition, so I'd really like to further solidify my knowledge of basic CS algorithms, definitions and principles to achieve a healthy balance between theory and practice.

Nice to see people interested in the topic. As a fellow enthusiast, for those willing to expand on this ideas and dive deeper, I really recommend: Clean Code: A Handbook of Agile Software Craftsmanship, by Robert Martin Along with his "Clean Architecture". Those are one of the best books I've ever had honor of reading. And, of course, one cannot forget about: Refactoring, by Martin Fowler

Yep, can't argue with that. Though that's mostly for tasks that are somewhat related to what you already created / modified yourself. Those can be estimated with a larger confidence. Unlike the other type of tasks when you're supposed to do something you've never done before.

Very true. Reminded me of Parkinson's law of triviality, which is an observation about the human tendency to devote a great deal of time to unimportant details while crucial matters go unattended. I have experience working with highly opinionated people, was one of those myself actually. Almost every code review was a passionate discussion, mostly about trivial things, not always though. Then I also have recent experience working with people who don't care at all about how X should be done as long as it's working and doesn't look like complete piece of crap. Actually scratch that, most of the project was written like there is no tomorrow. Nowadays it's somewhere in the middle, which I think is actually a great place to be. Trying to make a uniform code style for a team is a good effort, nothing wrong with that. Giving suggestions about why X should be done as Y (e.g. it's easier to read or less error prone) is fine. But I think one should always remember that the code we write as stable and long lasting as a fictional sitcom family. Or enriched uranium. Being too opinionated, to the point where only your opinion is the answer, is very stressful for everyone involved, even the person himself.

Quite the year, indeed. 📛 I finally got my OCP Java Programmer II certificate. Although perhaps I will never need it, but better than leave things unfinished, I guess. 🚀 Made a bold decision to quit my Java Developer position for 3 month to prepare myself for position of Scala Developer and was lucky to find a fantastic job, which also presented me with an opportunity to relocate to Saint Petersburg. 📙 Learned tons of new things: fundamentals of garbage collection in JVM, transaction isolation levels, RPC, functional programming principles (along with type-classes), a bit of cats and concepts behind cats-effect and ZIO , finally got my hands dirty with some real microservice architecture. All in all, it really feels like a productive year and I really hope the next one is going to be as well. Wish you best of luck in 2020, ladies and gentlemen . Let's enjoy the ride.