Learning
Isaac Asimov wrote almost 500 books in his lifetime—these are the six ways he did it →
Isaac Asimov was a hero. An awesome author and an ambassador of wonder. A master of science fiction with the science part remaining.
And he wrote.
A lot!
To match the number of novels, letters, essays, and other scribblings Asimov produced in his lifetime, you would have to write a full-length novel every two weeks for 25 years.
I know my productivity is nowhere near that. So how did he do it? The linked article has 6 reasons. Below is my take on them as a professional developer:
1. Never stop learning
That’s an easy one. If you stop learning in our profession, you’re done. The physics of programming is in constant flux. Hardware and network advances brings with them new application models. The fashion changes, so too does our user interfaces. You might be comfy at your current gig, but what about the next one?
Asimov read, a lot, about all kinds of different subjects. We too can learn the different nuances of development and bring our experience from other problems, languages and frameworks with us to our current problem.
Not only do we have books to learn from, think about the many learning opertunites online, from Pluralsight to MIT.
And if you ever get tired, retire to a comfy job at NASA. But that position has already been filled.
2. Don’t fight getting stuck
Getting stuck gives you an opportunity to work on something else for a while. Pair with a colleague, learn from someone, work on another task. Your brain is still working on the original problem while you’re busy doing something else.
In a personal setting without a team around to help, getting stuck on your most important project is OK if the second or third most important project is also important! Do not stress if the first thing on your TODO-list is not getting done, as long as other valuable task keeps being finished.
3. Beware the resistance
Self-doubt is the mind-killer.
Yes, what you create will have bugs, not everyone’s going to love it, it is not perfect and that’s OK. Do not let the fear of failure or what others think keep you from accomplishing your goals.
This is the resistance.
So try that hard task. Start, even if you do not see the whole solution yet.
4. Lower your standards
As in the former advice, you’ll not achieve perfection on the first try.
Never has that been more true than in software development. Iteration is the name of the game. Start small and build on it, every iteration better than the last.
And how do you know if it’s better? Let the user try it every step of the way.
5. Make MORE stuff
The more you create, the less each thing matters. Thus, if your just good enough app flopps, you’ll have your mind occupied with the next one.
This intensifies the peace and calm of his life.
This means no sacred cows. Being sentimental towards your creations is an activity for retirement. The code you wrote yesterday might be crap. And that’s OK, you’ll write more today.
6. The secret sauce
How did Asimov get ideas?
By thinking and thinking and thinking till I’m ready to kill myself.
This means that if your creativity got you down, do something about it. Take a break, change your physical location, brainstorm with your colleagues. Do not wait for a divine spark of inspiration, be proactive and work for it.
Conclusion
Turns out being a writer is hard work. It takes dedication and focus. Sometimes also sacrifice. You need self belief and a sense of self worth, even if others find your work lacking, all the while learning along the way.
This is also required for being an awesome developer.
NDC 2013 session videos are up
The videos of the sessions during NDC 2013 is now up on NDCOslo's Vimeo channel.
You can use the agenda to find more interesting topics.
I've updated my previous posts to include links to the videos of the discussed sessions:
- Day 1, high performing teams
- Day 2, architecture
-
The worst first world problem during NDC was deciding which sessions to watch live. Now I'm finally able to see what I missed.
NDC 2013, Day 3
Aka. the day of automated testing.
Sharing C# across Windows, Android and iOS using MvvmCross
MvvmCross is an excellent framework for data binding ++ on Xamarin's supported platforms. Stuart Lodge gave a talk explaining the motivation, history, philosophy and current state of the framework.
MvvmCross makes it easy to implement the MVVM-pattern on iOS, Android, Windows Phone, Mac, Win RT and others, and facilitates code sharing of the ViewModel logic across all the supported platforms. With the help of PCL (Portable Class Libraries), you can achieve code sharing in the upper 80%s of your code base. Even more if you use little custom UI. The view itself cannot be shared, and that is as it should be.
Properly decoupled view models are easy to test and with the code shared across all your platforms, the tests will have high value.
MvvmCross enables cross platform development with native UI and performance, together with easily testable code. I've used MvvmCross myself and highly recommend it to everybody interested in multi-platform development. For an introduction, check out the MvvmCross N+1 video series.
Succeeding with TDD: Pragmatic Techniques for effective mocking
Venkat Subramaniam gave an introduction to mocking in C# and helpful pointers when working with test-driven development (TDD).
- If your code is not testable, your design sucks. Separation of concerns, dependency inversion and the single responsibility principle helps with both design and testability.
- TDD takes you from unknown to known, one small step at the time.
- Start with your needs and map the world to you.
- Use mocks sparingly and keep them simple! Never make a mock more complex. If you hear "Do we need to write unit tests for the mock?" you have failed in this regard. An example:
[TestClass]
public class MockExample
{
/// <summary>
/// An interface for an imaginary stock service.
/// </summary>
public interface IStockService
{
double QuoteForTicker(string ticker);
}
/// <summary>
/// Class representing an application model.
/// Utilizes the IStockService in its implementation.
/// </summary>
public class SampleApplicationModel
{
private readonly IStockService stockService;
public SampleApplicationModel(IStockService stockService)
{
this.stockService = stockService;
}
public string CurrentTicker { get; set; }
public string LatestQuote { get; set; }
public void GetQuote()
{
var quote = stockService.QuoteForTicker(CurrentTicker);
LatestQuote = quote.ToString();
}
}
[TestMethod]
public void GetQuoteMustSetLatestQuoteForTicker()
{
// Simple mock, using an appropriate tool
var stockServiceFake = new Mock<IStockService>();
stockServiceFake.Setup(s => s.QuoteForTicker("AAPL")).Returns(700D);
var model = new SampleApplicationModel(stockServiceFake.Object) { CurrentTicker = "AAPL" };
// Mock with internal logic
//var model = new SampleApplicationModel(new StockServiceFake()) { CurrentTicker = "AAPL" };
model.GetQuote();
Assert.AreEqual("700", model.LatestQuote);
}
[TestMethod]
[ExpectedException(typeof(InvalidOperationException))]
public void GetQuoteLFailsMustSetErrorMessageAsQuoteValue()
{
// Simple mock, using an appropriate tool
var stockServiceFake = new Mock<IStockService>();
stockServiceFake.Setup(s => s.QuoteForTicker("AAPL")).Throws(new InvalidOperationException());
var model = new SampleApplicationModel(stockServiceFake.Object) { CurrentTicker = "AAPL" };
// Mock with internal logic
//var model = new SampleApplicationModel(new StockServiceFake(true)) { CurrentTicker = "AAPL" };
model.GetQuote();
}
/// <summary>
/// Complicated mock. Hard to understand, must be maintained
/// together with the interface it's implementing.
/// </summary>
private class StockServiceFake : IStockService
{
private readonly bool throwException;
public StockServiceFake(bool throwException = false)
{
this.throwException = throwException;
}
public double QuoteForTicker(string ticker)
{
if (throwException)
{
throw new InvalidOperationException();
}
return 700D;
}
}
}I would have stressed more that you don't start with TDD, you start with unit tests. Understanding how to write relevant and well designed tests are a precursor for a successful application of TDD.
C# 5
Jon Skeet, best known from Stack Overflow and as an author of the books C# in Depth, talked about async await in C# 5.
His focus was somewhat different from Venkat's previous talk. Rather than starting with C# threading basics, Jon made the case for async and await using metaphors and code examples. As we've previously learned, asynchrony does not equal parallelism.
C# in its current iteration has many different APIs for dealing with asynchrony. Your code will be easier to develop, understand and extend if you stick with one of these paradigms. Switching points between synchronous and asynchronous code can be painful.
Jon stressed the need for giving the user early feedback. For example, show items in a list as they come in. Don't wait for all the items before giving the user the option to work with the data. Also, validate input as early as possible so that exceptions caused by bad input do not happing during the asynchronous operations.
Testing was the last topic:
- Keep tests for plain business logic and asynchronous operations separate.
- Take control of time and consider using an abstraction so that the ordering of execution can be controlled from the tests.
- Test for different permutations of completion order for the different asynchronous tasks. The tests should still pass even if the code is run synchronously.
C# 5 lets you focus on the difficult bits... And that's good!
NDC 2013, Day 2
If the theme for my first day at NDC was high performance teams, the second day was all about architecture.
Asynchronous Programming on the .NET Platform
Venkat Subramaniam showed the evolution of asynchronous programming on the .Net platform. He started with "old school" manually created threads, and ended up using async and await from C# 5.
How does the user know your app is busy working and not broken?
I was reminded that about 250 ms are the longest an application should go without giving feedback to the user. This also applies to the application's startup time, which can be tricky in some situations. If startup performance cannot be increased within your development budget, a splash screen is your friend.
Seeing the differences between the asynchronous techniques in one coding session, made C# 5's improvements to clarity obvious. Thinking at a higher level of abstraction can be very powerful, but it also raises the bar for new users. However, every programmer today must learn to utilize more than one processing unit. C# 5's implementation of async and await is the most elegant I've seen so far in an imperative language.
People, Process, Tools – The Essence of DevOps
Richard Campbell gave me an introduction to DevOps. The discussion touched on some well known issues within a software organization, but it was still a useful introduction to the term DevOps.
This is the definition from Wikipedia:
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals
People, Processes and Tools, in that order, is the well known agile mantra and very much common sense. Richard talked about the challenges of cross-department and cross-team communication, and stressed the necessity of framing discussions constructively.
The one tip that stand out for me, was to focus on ROI (Return Of Investment) when discussing issues with stakeholders. For instance, if you cannot get managerial approval for faster hardware, document how much money the new hardware will save for the organization. Make it easy for others to make the right decision! Sun Tzu figured this out some time ago.
Other takeaways were:
- Document every project. Do not let problems or work go unnoticed.
- One step environment creation! Utilize virtual environments, preferably configured like production.
- Shorten and amplify all feedback loops.
- Take ownership of numbers that matter to you.
The Architecture of Uncertainty
Kevlin Henney is one of my favorite speakers, and I've been to many of his talks in the past. He has impressed me before by being one of the few speakers using sources from the scientific literature and not just anecdotes from his own experiences. If our field is to mature and improve, more educators outside academia must do this.
What is software architecture? Kevlin has previously used the definition put forth by Grady Booch:
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
Therefore, we should
Avoid decisions at the point of most ignorance.
This have profound consequences. Don't lock in your decisions to early! We can use the stuff we are unsure about to help us define our architecture. Every point of uncertainty is a chance to introduce an abstraction such as an interface, enabling us to continue working without having to consider every detail all the time.
Partition the application along the lines of which you are uncertain.
Such thinking can improve the quality and speed of our work. It makes the gaps in our knowledge apparent and enables us to move forward in a constructive manner. As we come to know our project and domain better, the quality of our decisions will improve and it will be easer to fill in the gaps from before.
NDC 2013, Day 1
NDC (Norwegian Developer Conference) is a yearly developer conference taking place in Oslo, Norway, with a focus on agile methodology and Microsoft technology. However, a lot of talks are technology agnostic, and the attendees are a diverse group of people.
Day 1 of the conference had some real gems and here are some highlights.
Accelerating Agile: hyper-performing teams without the hype
The first talk I attended was Accelerating Agile: hyper-performing teams without the hype by Dan North. Despite the hyper title, Dan delivered anecdotes from his work in the trading business with confidence and flair. He had many valid observations (IMO) regarding what drives effective teams. Some examples include:
- Train the developers in the domain og the business and have domain experts connected to or be part of the development team.
- Don't be afraid to try something new, be it technology or process. A corollary is: Be OK with "failure". Product development is not project delivery.
- Prefer simple over easy. Simple is the buzzword of the day, but it is still underrated. Easy can lead to more problems down the road. Think frameworks that do to much or taking on to much unnecessary technical debt.
Clean Architecture and Design
Next up was Robert C. Martin with his talk Clean Architecture and Design. As usual he started with a fun fact, then a history lesson. What followed was a good talk regarding components, their boundaries and responsibilities and unnecessary complexity in systems.
- "Architecture is about intent". You should be able to discern the purpose of your system by looking at your architecture. Think normal architecture blueprints.
- Inputs and outputs should be plugins to your system. That includes the GUI and the database.
- Wrap external dependencies such that they can "easily" be replaced.
- A good architecture allows you to defer decisions.
Patterns of Effective Teams
Patterns of Effective Teams, another excellent talk by Dan North.
This talk was even better than his last one. Dan described patterns he and his teams have found useful, describing the situations and the persons involved. The patterns included:
- Dreyfus squares, pair developers of compatible skill levels.
- Make new hires feel welcome. Take care to introduce them to the organization, give them task related to their skill level and make sure they get some early wins.
- Keep your daily Scrums (or equivalent meetings) effective and useful for the whole team. If the team thinks of the meetings as energy drainers, change the meetings make them useful for your team and situation!
- Code critique. Learn from other peoples code, and give the team opportunities to learn from each other. Code reviews should be an energizing and positive experience. Make the novice review from code from an expert to facilitate learning and teaching.
Edit: I've added links to videos from the sessions.
Top 5 podcasts for developers
Over the years I have listened to a lot of different podcasts, some good, some bad, most mediocre. I think podcasts can be useful for discovering new ideas, challenge our perceptions and making the commute to work seem a bit shorter. The podcasts outlined below are the ones I listen to regularly and should interest most developers.
Hanselminutes
Technology talk that doesn't waste your time.
Scott Hanselman covers different technical topics, primarily from the .Net world. He is an excellent interviewer and keeps you up to date on whats moving in our industry.
hanselminutes.com/ (Updated weekly)
Build and Analyze
A weekly news and discussion show about the world of iPhone, iPad, iOS, and mobile web development.
Marco Armen is the creator of the excellent read-it-later service and App, Instapaper. This is his show and the audience get a window in to the world of independent app-developer. Different perspectives than you get from your regular enterprise employee no 1000.
5by5.tv/buildanalyze (Updated weekly)
This Developer's Life
Bringing a human slant to the tech industry.
Rob Connery and Scott Hanselman talk to noteworthy programmers and themselves about the many different aspects of software engineering and the effect it has on our lives as professional developers. Many interesting stories told by the people who made them happen.
thisdeveloperslife.com (Updated sporadicly)
Software Engineering Radio
Software Engineering Radio is a podcast targeted at the professional software developer. The goal is to be a lasting educational resource, not a newscast. Episodes are either tutorials on a specific topic, or an interview with a well-known character from the software engineering world.
This is the most technical podcast of the bunch. Many interesting interviews and different perspectives from around the industry.
se-radio.net (Updated every ten days)
The Skeptics' Guide to the Universe
The Skeptics' Guide to the Universe is a weekly Podcast talkshow discussing the latest news and topics from the world of the paranormal, fringe science, and controversial claims from a scientific point of view.
This is my personal favourite. No coding in this show, however you learn important skills such as critical thinking, be able to spot logical fallacies and gain a greater understanding for how we know what we know. These skills are invaluable in any profession. Is TDD worth it on a company wide scale? Has Scrum yielded more successful projects than other methodologies? Does pair programming improve code quality? Does high code coverage lead to fewer bugs in production? Do you know? How do you know?
theskepticsguide.org (Updated weekly)