The fear of an empty source file
I have been writing software at this point for over twenty years, and I want to believe that I have learned a few things during that timeframe.
And yet, probably the hardest thing for me is to start writing from scratch. If there is no code already there, it is all too easy to get lost in the details and not actually be able to get anywhere.
An empty source file is full of so many options, and any decision that I’ll make is going to have very long lasting impact. Sometimes I look at the keyboard and just freeze, unable to proceed because I know, with a 100% certainty, that whatever I’ll produce isn’t going to be up to my own standards. In fact, it is going to suck, for sure.
I think that about 90% of the things I have written so far are stuff that I couldn’t write today. Not because I lack the knowledge, but because I have far greater understanding of the problem space and I know that trying to solve it all is such a big task that it is not possible for me to do so. What I need reminding, sometimes, is that I have written those things, and eventually, those things were able to accomplish all that was required of them.
A painter doesn’t just start by throwing paint on canvas, and a building doesn’t grow up by people putting bricks where they feel like. In pretty much any profession, you need to iterate several times to get things actually done. With painters, you’ll typically do a drawing before actually putting paint on canvas. With architects will build a small scale model, etc.
For me, the hardest thing to do when I’m building something new is to actually allow myself to write it out as is. That means, lay out the general structure of the code, and ignore all the other stuff that you must have in order to get to real production worthy code. This means flat our ignoring:
- Error handling
- Control of allocations and memory used
- Select the underlying data structures and algorithms
- Yes, that means that O(N^2) is just fine for now
- Logging, monitoring and visibility
- Commenting and refactoring the code for maintainability over time
All of these are important, but I literally can’t pay these taxes and build something new in the same time.
I like to think about the way I work as old style rendering passes. When I’m done with the overall structure, I’ll go back and add these details. Sometimes that can be a lot of work, but at that point, I actually have something to help me. At a minimum, I have tests that verify that things still work and now I have a good understanding of the problem (and my solution) so I can approach things without having so many unknown to deal with.
A large part of that is that the fact that I didn’t pay any of the taxes for development. This usually means that the new thing is basically a ball of mud, but it is a small ball of mud, which means that if I need to change things around, I have to touch fewer moving parts. A lot fewer, actually. That allow me to explore, figure out what works and doesn’t.
It is also going directly against all of my instincts and can be really annoying. I really want to do a certain piece of code properly, but focusing on perfecting a single door knob means that the whole structure will never see the light of day.
Comments
Just start with a blank file. Throw away all frameworks, implement just the code that you care about and see the results on console - the best moments in the project lifetime. Then you throw in the boring stuff and complexity - frameworks, plumbing code, UI spaghetti - and you know there will be no more fun there.
I have a very similar way of work with some differences:
1) Always start with Dependency Injection setup. Setting up DI allows you to skip a lot of the cross-cutting concerns by registering simple no-op services, and helps testing tremendously. 2) Error handling. Setup at minimum exception logging then gradually add more logging. Decide on a generic logging abstraction to use. 3) I really hate O(N^2), so I try to at least make sure whatever lookups can be O(1) are O(1) by using dictionaries (Linq .ToDictionary(), is very convenient). (Not optimizing for memory consumption at this stage) 4) Logging, monitoring, visibility ... start with the bare minimum, and try to use SaaS drop in solutions. 5) Refactoring ... I can\t skip this stage else I feel I've done a crap job. Resharper is extremely useful here, and once you know the key shortcuts you can make hours worth of refactorings (Regular VS) in minutes using Resharper.
The most important thing for me is feeling I have a good start regardless of how little of the cross-cutting concerns are covered at first.
Thanks, nice writing. I have very similar experience. When I want to write something perfect, I will get stucked with overcomplicated code...
Hi Oren... I take a 100% opposite view, and it works for me time after time. Over very many years as a freelancer, I've built up my own library of snippets, tools, utilities - a framework of my own, if you like. I never start with a blank source; I start by adding all the things I know I will need (like error handling, logging, login, database access) so that when I start writing code for the business domain, I can include this stuff from the very first iteration, with (usually) just a line or two of code.
You say "When I’m done with the overall structure, I’ll go back and add these details. Sometimes that can be a lot of work, but at that point, I actually have something to help me." but I find that, no matter how carefully I plan, it's almost inevitable that some of those "details" will get forgotten about, or whole chunks of functionality will miss some underlying essential, if I develop using your approach. I start building applications with the bits that are closest to the generic model (e.g. the login screen, adding any domain-specific functionality) and usually then user maintenance (if required). This builds up an increaasingly-specific structure that grows organically to encompass the entire application.
Works for me, anyway! (I'm a solo freelance developer, usually the only tech person working with a SME, so I do have a lot of freedom in my approach). I build web applications using ASP.Net Webforms, C# or VB.Net, any SQL database, HTML / CSS / Javascript. The only 3rd party framework I use is JQuery.
Hi, I agree with every word. Thanks, nice writing
I start by writing a test. That then guides what code I want.
Comforting to know others feel the where to start delemia. Templates can be a good because they give you something to look at and a place to put your first line of code.
Over 20 years ago I worked with an old mainframe programmer who said the way he wrote programs was to create a new file, put in a BALR and USING, then just keep debugging it until it did what it was supposed to.
The primary concern with this way of coding, however, lies with the fact that we will be stuck with code most of the time that needs to be re-written again. I would rather investigate the optimum algorithms first, create a design/code model that helps me in leveraging those. Frameworks definitely will come in for logging, testing etc.
Derek, Are you working on (roughly) the same type of application? When I'm talking about building something new I'm not referring to another project doing the same thing in a different business context, but doing something that I have no knowledge of. The example that I had in mind when thinking about this post is the graph queries in RavenDB. That involved API (the query language), the optimizer and the actual query processor. That is a lot of unknowns to juggle at the same time, and having anything extra means that I would have to worry about them as well at a period of rapid changes.
Comment preview