- Expect to experience an emotional response to criticism. I went into the office of SRT Solutions with the selfish purpose of learning how to be a better Scala developer. I wanted to reduce the learning curve and was grateful for the feedback I received. Still, I could feel the blood rush to my face as I was following the direction of the group. I felt hot as I was moving code as fast as I could in response to the input I solicited. This response took me by surprise. We humans are emotional creatures. While we should seek to grow by exposing ourselves to uncomfortable situations, we will still experience discomfort while growing.
- Don't abandon SRP just because you are working in a more powerful language. SRP is the Single Responsibility Principle. In my simple mind it means: At any level of abstraction -- closure, function, class, package, or project -- do one thing and do it well. Unlike Java, Scala allowed nesting functions. This allows you to bury implementation details in a method without having to create private methods or an object model for delegation. With this power comes responsibility. You want your code to be expressive. Don't force the developers who come behind you to wade through a bunch of closures of implementation details just to figure out what a method is doing.
- Don't be afraid to write ugly code, but go back and clean it. This is not a new lesson, but I wanted to contrast the previous point regarding SRP. Since Scala is more powerful than Java, try to find out where nested methods and other constructs make sense. Push the boundaries, then scale back to what is reasonable. Be an expert in cleaning ugly code. Write code fast, but take a step back with every success and think about the person who has to read your code. Be fiscally responsible with their time. Developers spend more time reading code then writing code. Be willing to sacrifice 10 minutes of time for code cleanup to save 30 minutes of the next developer's time.
- Don't be in a rush to dial up your Scala skills to 11. Scala is an evolving language. The language developers and enthusiasts continue to debate and refine the core language features. Be judicious about the language features you integrate into your applications and systems development. You don't want to rely on a feature that may be deprecated in a future release.
- Not everyone should be a language developer. Even though the name Scala is derived from the term "Scalable Language", don't think that you need to develop a robust DSL (domain-specific language) for every business problem. Do you really need the overhead of that implicit converter just to make your code read like English text?
Much gratitude to Diane Marsh and the Ann Arbor Scala Enthusiasts group for freely giving me these lessons. I encourage you to seek out people who have blazed whatever path you are currently taking in life.
