Pluralsight Reviews: Android For .NET Developers, Parts 1 & 2

I’m getting started with Android development in my scarce spare time.  In order to get me past the “Java is scary and stupid and I hate it and it’s stupid” part of this, I decided to watch Jim Wilson’s Android for .NET Developers series.  So far, I’ve watched Part 1 and Part 2.

I think Part 1 is a little hit or miss.  Wilson starts off great, showing how to install the Android SDK.  I’d recommend ignoring the Eclipse part and just download Android Studio and watch section 6 on Android Studio.  The product has matured a good bit since Wilson did his course, so you won’t have to do the same workarounds that Wilson showed.

I think Part 1 started to slip once Wilson started to talk about Dalvik Debug Monitor Server.  Debugging and monitoring is vital, but honestly, I think that would have been better-suited for part 2 or part 3.  I get that you want to get people off the ground quickly, but until I have code that I could reasonably debug, it’s hard for me to get excited about a debugger.

Part 2 was fantastic.  Wilson walked through a few basic applications.  If you follow along in the code, you’ll have some basic applications which can make use of external resources like the camera, and which can also span several activities.  Wilson’s depiction of the activity lifecycle is also excellent and really helped me understand what happens behind the scenes on my Android phone.

I haven’t gone through parts 3 and 4 yet, but when I get a little bit of time, I want to jump back into this topic.  Once I complete the next two parts, I’ll have a separate review for those.

Pluralsight Review: Building NoSQL Apps With Redis

Not too long ago, I decided to learn a bit about Redis in preparation for using Azure Redis Cache.  I checked out a few links and also watched John Sonmez’s course entitled Building NoSQL Apps With Redis.  Sonmez did an outstanding job of walking through how Redis works, how to set it up, how to connect to it, how to work with cache keys, and even how to chain together Redis nodes.  The last hour of his course handled building an MVC project with Redis as the back-end store.  Honestly, I don’t think I ever would want to use Redis as a source of record, but it’s easy to think of scenarios in which I’d use the decorator pattern and wrap a Redis call around SQL Server or a web service call.

If you need to learn about Redis, Sonmez’s course is a fantastic place to start.

Pluralsight Review: Communications

About a month ago, I listened to Paul Randal’s Pluralsight course entitled Communications:  How to Talk, Write, Present, and Get Ahead!  I consider Randal a top-notch communicator, and so I was definitely interested in hearing what he has to say.  This is a short series at just 2 1/2 hours, but definitely worthwhile.

My biggest take-aways from this were:

  1. Keep e-mails short and succinct.  Have one or two questions and make it clear if you expect an answer.  I used to be terrible about writing novellas to co-workers, but I eventually realized (before this course reinforced the habit) that I need to write concisely.
  2. Do not have a meeting without an agenda, and stick to your agenda.  Don’t waste time in meetings, and don’t be afraid to move a topic to its own meeting if necessary.
  3. Practice for presentations and expect anything to happen.  I’ve had my PC reboot in the middle of a presentation.  This is a talk that I’d given a couple of times, so I was able to continue with my “lecture” portion, and by the time the machine was back up (thank goodness for solid state drives!) I could pick right back up where I’d left off.  Whatever happens, don’t panic.

Pluralsight Review: Management 101

Jason Alba’s Management 101 is a good primer on management, especially in a technical environment.  Managers have two jobs:  get the most out of their employees and protect their employees from the outside world.  Alba’s quick course is filled with interesting tips on how to do that, as well as handling difficult scenarios like managing people significantly older or more experienced than you.

This course got me thinking about people I considered good managers.  The most important thing about a good manager is knowing that different people have different buttons to push:  some people need and want to be micromanaged; others (like me) despise micromanagement and want specific long-term goals and extremely broad scope to achieve those goals.

Code Is A Liability

I love deleting code.  I like getting rid of unused code, reducing the amount of code in my code base, and making sure that the remaining code is adequate to the task.  I think that this is so important that I even wrote a series which focuses in part on minimizing code.  I think that a good developer could walk into any non-trivial environment and find, with a nominal level of effort, 10-20% of the code base which could be eliminated entirely and nobody would notice.

The title of this post, as well as my introductory paragraph, is deliberately provocative.  Nevertheless, I believe that it is entirely true.

When most people think about code, they think about the end result:  the applications.  They tend to equate “the code” with “the application.”  In reality, those are different:  a particular code base is one way to achieve a specific application result.  The application itself is an asset; people are interested in that application inasmuch as it provides use value to them.  The specific details of underlying code has no bearing on their use value of the application itself.  In other words, if you could take a million-line code base and refactor it into 100,000 lines, it would provide no direct benefit to the end user in a steady state.

So why do I push so hard for refactoring code?  The reason is that it provides value to users and to those producing and maintaining the code over time.  Every line of code which exists in an application is a line of code which somebody needed to write, somebody needed to test (hopefully!), and somebody needs to maintain.  Those are all direct code costs.  In addition to those costs, there is a cost of new features.  With an ossified code base full of junk code, writing a new feature is significantly harder; there are many more dependencies, more places for code to break, and more undocumented expectations than in a clean code base.  By refactoring code vigorously and improving the code base, we reduce the time-to-market for new features, providing additional value to the end user.

To use an analogy, let’s say that I make a wooden chair.  My amount of effort is a liability:  it is a direct cost that I, the seller, incur and which provides zero value to the buyer.  The buyer wants my chair because of its quality, not because of the number of hours I put into it.  If my process is very inefficient, I might not produce enough chairs or chairs of a high enough quality.  I grant that this analogy is imperfect, but hopefully it clarifies more than it clouds.

Pluralsight Review: Clean Code: Writing Code For Humans

There’s an adage with developers:  write code that the complier can build and humans can understand.  Compilers are relatively forgiving when it comes to poorly-named objects, excessive use of copy-and-paste, incorrect comments, and unnecessary complication in code.  Humans, on the other hand, tend to get confused a lot more easily, and so you should focus your code on satisfying the latter constraint.

Cory House has a Pluralsight course full of tidbits that help you write cleaner code.  I watched this not too long after reading The Art of Readable Code, and these two resources fit together quite well.  Much of the advice is simple, but House walks through the topic in an understandable manner and ties together a few basic themes.  Watching this series has helped me think more concretely about how I can improve the code that I write, which helps out me as well as my co-workers and successors.

Even though House’s course focuses on object-oriented development, I think there are a number of things that a T-SQL developer can take from the course, particularly when it comes to branching logic, appropriate use of comments, and attribute and variable naming.