You know this by now but my university English professor is a mean sucker and would hunt me down if I didn't provide context for this post. Microsoft will be shipping jQuery with ASP.NET MVC and Visual Studio. I imagine there will be lots to Google about this in the coming days but you can start at the source: ScottGu, ScottHa, John Ressig.

I freakin' LOVE this news if for no other reason than I finally have a counter argument to the MVC mainstay complaint "what about my server-side controls?". According to John Ressig's post, Microsoft will be developing controls on top of jQuery. Combine that with the news that Visual Studio will have IntelliSense support for jQuery and you have yourself a happy codin' hillbilly.

My underlying interpretation of this is that Microsoft will provide reasonable alternatives to the stock server-side controls using jQuery instead. Rob Connery has already provided a pretty detailed tutorial on creating a paged grid in MVC, and he didn't even use jQuery.

Oh yeah, and this is a bold new direction for Microsoft and they're welcoming Open Source and the community and blah blah blah. Whatever, as long as I have something else to say besides "yeah, well, you smell" to people unwilling to give up their GridView.

Kyle the Argumentative

Not feeling too subtle today so I've given the punchline away in the title here. After wandering neck-deep into MVP and MVC, I'm now thinking about refactoring brownfield applications toward them. And it occurred to me: is it reasonable to refactor to MVC? Then, is it feasible? Then, is it even possible?

I've built started three or four MVC applications and love the framework for greenfield apps. But assuming you have a nice, healthy (and I'm using the definition "of great size") web application, would you go through the exercise of converting it to MVC?

Here are some reasons why I wouldn't.

First and foremost, your URLs will change. Instead of http://myapp/ProductList.aspx, you have http://myapp/Products/List. Depending on the size of the app, I'm not sure I'd trust a global search and replace for that. Besides which, I'd rather be using one of the helper methods to generate the URLs in MVC.

Granted, you might be able to get around this with some combination of HttpHandler or HttpModule. Whether or not there is enough benefit to be gained from MVC to go through this exercise probably depends on the size of the app, your deadlines, and just how much blogging material you want to generate.

This segues into my next point. Unless you plan to refactor every page all at once, you need a way to have WebForms pages sitting along side MVC pages. Which means you need to be able to navigate directly to some .aspx pages in some cases, and to controller actions in others. This might be possible in the same project but it makes my head hurt thinking about it. You'll be giving the routing engine a hernia with all the heavy lifting it would have to do. Either that or, again, implement your own HttpModule before the routing module in the pipeline.

Alternatively, you'd create a second web project, an MVC one, and move your UI over to it over the span of many moons. Your URLs will really get messed up as you'll be essentially working in two separate web applications.

All of this presumes your logic is separated enough to withstand such a change. When talking about refactoring to layers in the brownfield book, we recommend doing so incrementally. That is, start by creating a seam and move all the code into it leaving a little bit behind in the UI. Then repeat for the big bulk of code you moved all the way down the line to the data access. (There, now you don't have to read Chapter 8.)

Refactoring to MVC feels like this would be hard to do. Mind you, it shouldn't really be any harder than refactoring to MVP. Maybe just feels that way because of the brownfieldedness of the apps I have swirling in my head. (Full disclosure: many of which I contributed to.)

Speaking of MVP, one of the main reasons I think this is too much work is because MVP is such a reasonable alternative. Maybe not 100% idea, but it's a very viable compromise. On the one hand, yes, you still have to deal with the ViewState and the ASP.NET Pipeline and all the happiness that comes from trying to separate concerns in a real application as opposed to the contrived examples in books and blogs that make it look so easy. On the other hand, it's less work to attain and in the end, you'll end up with a more maintainable application.

So after all this windage about why I wouldn't refactor to MVC...has anyone...y'know...tried it?

Kyle the Armchair Refactorer

When presenting on ASP.NET MVC, I use an application I started nigh on two years ago when I was a wee whelp extolling the virtues of Atlas. It's no longer AJAX-y but it does demonstrate MVC and I've put it online at Google Code mostly because I've been promising I would for many months.

It's a music catalogue that will extract metadata from all WMA and MP3 files in a folder of your choice and store it in a database. There are some simple controller actions used to query the catalogue in various ways.

Check out the ReadMe.txt file for some tips on getting started. Note that you can't just download the code and open it up in Visual Studio. You need to run the build file at least once. There is a batch file that will make this easier the first time (clicktobuild.bat) but bear in mind that this *will* drop and re-create your database. And before you do that, you'll need to create a local-properties.xml file in the confi--...actually, just read the ReadMe.txt.

There is a unit testing project in there that I added after the Edmonton presentation. The Edmug guys have whipped their city into shape there because when I said MVC is conducive to TDD, they called me out and said "Prove it, Plaid Man". Hardly complete coverage by any stretch but hopefully demonstrative enough.

If you're semantically inclined, this does indeed mean I built the app without using TDD. There's actually a very good reason for that. You see, a plague of locusts appeared when I was first building it and they told me in locust-ese that if I used TDD, they would become a blight upon the land. I'm sure you see my dilemma.

Final note on the name. Suvius is just a code name my brothers and I use and I've always liked the sound of it. Flamingo is the national bird of the Bahamas. How do they relate to an online music catalogue application? They don't. I've got a rant I've all but memorized on people's fixation on names but the short version of it is: Amazon, Sun, Java, Oracle, eBay, Facebook, Windsor, and Hibernate.

I'd tell you to enjoy but that implies some sort of emotional attachment to the project.

Kyle the Flaming-o

Over the summer, the hillbilly sold his Canadian trailer to a pair of lovely ladies who I will assume are sisters even though they look nothing alike. A goodly pile o' the proceeds has been put to good use but I shan't elaborate.

A nice little chunk of it has been reserved to upgrade the computers in the homestead. And for no other reason than "because I want to see what the hubbub is about", I'm looking seriously at Macs. (Actually, that's not true. I do plan to spend hours playing with Photo Booth.)

To qualify that rationale, I will point out that my experience with Dell over the years has been good, bordering on excellent. I've had my share of Dells over the years and have ordered two at least bi-annually for a regular client.

I won't lie by saying they've all worked flawlessly but, and here's the important part, Dell has been efficient at fixing the mistakes. And I mean crazy efficient. The client travels ten months out of the year and is not always in the most convenient location when things go wrong. But Dell has shipped replacement parts to countries I can't even pronounce or spell under some pretty stringent deadlines. Plus they have done warranty work here in the Bahamas on at least three occasions, which is a feat in itself. Compare that to my experience with Sony which was a lot more frustrating than that link lets on.

Two nights ago, I ordered a replacement Inspiron for my wife through her company. Total elapsed time was about fifteen minutes. Dell ships direct to the Bahamas and calculates shipping, stamp tax, and duty accordingly. (There's no duty on laptops but there is on parts.) Like most international companies, their website experience still isn't quite up to par if you live in the Caribbean (for some inexplicable reason, the Bahamas is considered part of Latin America) but it's better than most.

But just the same, I want to give a Mac a shot.

Today, I finally started looking into logistics for getting an iMac out here. I started with the local computer store because I prefer to buy locally when I can. As luck would have it, they are an authorized Apple reseller. After a few minutes on the phone, the salesman came back with a price of just over $3550. Same computer on apple.com: $2318. To put that into perspective, I could fly to Florida, stay overnight in a nice hotel, buy my computer, and fly back for cheaper. That doesn't take into account the savings I'd get on peripherals, like a 1Tb Time Capsule, which the local company wants over $900 for. (To counter the servicing argument, the local company does provide service for Apple. And Dell. We've used them. They're actually pretty good.)

Next stop: apple.com. That was an easy one. They are very clearly not set up to ship to the Bahamas.

Third option was to phone Apple directly, which was entertaining. Trista was very sweet and perky until I asked "Is it possible to order a laptop and have it shipped to the Bahamas?" At that point, she got, let's say, "nervous". Actually, let's say, "jittery". Actually, it was downright frightened, like Steve Jobs himself was hovering over her shouldering saying, "You export that MacBook and I'm implanting a device into your body that will give you and the next three generations of your family permanent halitosis. And you know I can do it."

Seriously, she went from "Perky Saleslady With 43 Pieces of Flair" to "Let me get out the CSR Manual of Canned Responses and read directly from the page on dealing with potential smugglers".

A couple of weeks ago Scott Reynolds posited that Apple isn't ready for corporate adoption. Based on this experience, I don't believe they are ready for internationalhood. And I'll qualify that by saying at least not at the same level as Dell. I know you can get MacBooks at any local convenience store in Canada and the UK. But Dell makes it almost as easy to do the same in our rather under-populated neck of the woods.

And I don't necessarily begrudge Apple based on this one experience. The reality is, the Bahamas is a country of 300,000 people. It may not make financial sense to deal with customs and import duties and stamp taxes and bribing government officials in order to reach out to the people. Better to leave it to local retailers who have a better sense of the demand.

But don't equate an open mind to giving them a free pass. So far, they fit snugly into "mediocre" territory when it comes to the buying experience, and I'm still very early in the process. The only reason I tolerate it is because they aren't the only offenders by any stretch. I'm calling them out specifically because: a) I work with computers, and b) I expected more from them.

Kyle the Un-macced

I have kind of a love/hate thing going for Roy Osherove's blog. The "hate" part comes because he always challenges my perspective when I least expect it. Some of his posts seem like they are baiting people and it is easy to discount them as biased based on his position with TypeMock.

But given what I think I know about him, I read these "inflammatory" posts with a different view. That is, as someone who is challenging the view of my personal echo chamber. I read tons of posts extolling the virtues of mock objects and Rhino Mocks. So it hurts my little brain to see someone I respect saying it's okay to keep your current "creative" design and still be able to test it.

It starts, "Yeah, whatever. Like I'd ever do that." Then I start mulling it over and grumble to myself, "well, I guess that would have made sense in this past situation", then "actually, that makes sense for quite a few scenarios." Eventually, the train of though leads to my lying on my bed sobbing on the phone with my old employer to apologize for the colourful analogies I made to describe his project when I was unceremoniously let go for rocking the boat too much. Which is an interesting thing to account for when drawing up the timesheet for my current contract.

Anyway, this Roy-love isn't the real reason for this post but hopefully, you're used to the hillbilly's verbose lead-ins.

Roy's most recent post is another example of one that seemed bound from the beginning to give me a headache just from the title alone. But luckily, it touches on a subject I've thought about before, particularly when dealing with the fledgling Bahamian software industry.

I won't paraphrase because chances are, you've read it already but the question it tickled in my mind was, "Are the best practices I've adopted over the last two years practical?"

I've mentioned this a little before from the perspective of a small application for my family who can't afford a senior developer should I take up shark-baiting in the near future. And it's going to be hard to talk about this without sounding elitist so I'll call up the good will of my 98 previous posts at CodeBetter and hope y'all assume the best.

I took JP's Nothing But .NET course over a year ago and had an absolute blast. But quite a lot of people struggled with it. Since then, I've made a more concerted effort to learn more about things like mocking, dependency injection, the SOLID principles, etc, etc, and so on and so forth. It hasn't always been easy but it's been tremendously rewarding. Learning all of it has made development fun again. Plus it's allowed me to connect with a ton of other people both as mentor and learner. And as a mentor, I've seen my share of people struggle with it. Even before I started, I saw a lot of people fight to understand things like AJAX calls, NAnt scripts, even CSS.

By all accounts, these are reasonably bright people. They want to do a good job and are receptive to new ideas. But quite frankly, some of these things are hard. Let no one forget that learning how to properly use mock objects is *not* an easy task and until you "get" them, they will seem like unnecessary overhead. I resisted TDD for many a moon. Even today, it's still not quite second nature. That's mostly because I'm stuck in Livelink-land these days which contains code that would make Michael Feathers shake his head in defeat.

When I entertain these thoughts, it's usually a battle between "should we cool our heels a bit until we hit the tipping point" and "should we keep going full tilt until the message starts getting across". As Roy mentions in his point, the learning curve is high. Do we keep pushing the learning so that more people get over it or do we lower the learning curve until most people get it, then raise it a little?

I'd like to think we can do the first. The second seems like giving up. And worse, if we start to "dumb things down" in actual projects, it will be that much harder to actually lower the learning curve because no one will be pushing the boundaries. No Fluent NHibernate, no MvcContrib (or even ASP.NET MVC), no StructureMap. We've all seen what teaching to the lowest common denominator has done for the North American education system.

Yes, we can put the onus on programmers to "do a better job" but let's face it, these people have lives. My dad is a land surveyor and my mom was a registered nurse. By all accounts, they were/are very good at their jobs and I remember very few instances of them taking their work home with them or advancing their learning outside of their work. With software development, it is almost expected that if you want to get better, you need to do it on your own time. And when you're done, you face going in to work to find that the rest of your team hasn't done their part and thus, are not amenable to the changes you want to make.

So how far can we reasonably push people? The work needs to actually get done and it seems a good chunk of programmers still don't put any special effort into making code maintainable over the long term. Do we need to change the message? Or the medium? Are user groups and code camps doing their part or simply enforcing the status quo? Is alt.net making a difference or fragmenting the industry? Or simply being ignored?

Will be interested in hearing people's comments on this as I actually have an over-arching reason for this line of questioning.

Lord Tunderin' Jayzus, what a friggen essay this turned out to be. Now I gotta go dig up a couple of halfway-relevant images to balance out this tome. Serves me right for thinkin'.

Kyle the Introspective

What's the first thing you think of when I say "Bahamas in February"? If you said "code", then you're my target audience for this post.

First, a recap of the BahaNET meeting last Thursday night. We finally hit double-digit attendance for the first time which is very exciting, even if the number includes yours truly. A midway surge of three people added 40% to the numbers to bring us to the coveted "ten people". It was very exciting. Especially considering the topic was version control.

But that's not what I came here to talk about. Something that's been nagging in the back of my head for some time now is the possibility of an event in the Bahamas, hopefully next February or thereabouts. I don't want to call it a code camp just yet because I'm not sure that's what I want to do. A code camp seems local in scope and I'm still trying to figure out if we have the user base to justify it.

Another option is to make it more summit-y. I.e. invite people from around the world for a nice little software development love-in. What can we offer that other conferences don't? Well, nothing from the professional development side of things. But just the same, I think we'd have a decent turn-out for some reason. I've had a *lot* of interest in this option. Not sure how much of that will translate to actual plane tickets being booked but it's encouraging nonetheless.

There is a downside to the latter option that I think is pretty important. We would lose the local focus. I think there is still work to be done within the country before we start inviting software heavyweights down here to talk about functional programming and DDDD.

Which leads me to another option, and I swear I had this in mind before Kaizen came out. Instead of a code camp where there is presentation after presentation, I'd like to hold two days (minimum) of practical workshops. A workshop would be four hours long and ideally, we'd have at least two or three "tracks", with at least one of them geared very much toward beginners. At least on the first morning.

I believe this would offer the best of both worlds. The local development community could benefit from some hands-on training and the global community could pass on their knowledge in between margaritas on the beach.

I do have a medium- to long-term plan for the industry in the Bahamas. Realistically, a full day of 75 minute presentations doesn't fit in with that goal right now. And as much as I would love to invite the world to the Bahamas for Caribbean TechFest so we can debate the pros and cons of IronRuby, that isn't going to help the fledgling software industry in my adopted homeland.

I've been talking with some people rather vaguely about some of this already for some time and I suppose this is simply a way to try to crystallize things in a semi-permanent format. I'd be eternally grateful to anyone who can provide constructive feedback and/or advice on any of this as February is not quite as far away as I would hope.

Kyle the Planned

Yes, I know you've read this before so stop rolling your eyes and skip it if you're not interested. I'm not coming at this from the perspective of an expert imparting knowledge but as a hillbilly who has ignored the question too long. And now that I have to dive into it for the book, all the vagueness that I've been able to shunt aside to a little corner of my brain has surfaced like a long-lost brother beggin' for college money.

So since I work from home without a lot of peers, my options are to talk it out here or to my daughter, who cries when her favorite singer is kicked off American Idol.

Pre-requisite reading:

Martin Fowler on GUI Architectures
Martin Fowler on Passive View
Martin Fowler on Supverising Controller
Martin Fowler on Presentation Model
Jeremy Miller on the difference 'twixt MVC and MVP

I've looked through a number of other links but these are the ones I feel provide sufficient background and are suitably authoritative. Plus, I don't want to rehash the definitions of each pattern.

So as I was waxing eloquent on Passive View and Supervising Controller, the thought crossed my mind, "I'm not seeing a lot of difference 'twixt these and my understanding of MVC. They have the same components and the diagrams look similar enough..."

Martin Fowler's contrast between the two didn't help much:

MVP uses a Supervising Controller to manipulate the model. Widgets hand off user gestures to the Supervising Controller. Widgets aren't separated into views and controllers. You can think of presenters as being like controllers but without the initial handling of the user gesture. However it's also important to note that presenters are typically at the form level, rather than the widget level - this is perhaps an even bigger difference.

The problem stemmed from the way I'd explained the difference in my recent presentations on MVC. Specifically, I said that in MVP, the entry point was the View (aka. the aspx page) while in MVC, it is the Controller. While this is technically accurate, I now think it's a consequence of the *real* difference.

Another thing blocking my understanding was that I spent too much time reading the theory and not enough time just reviewing my own code. I've implemented Supervising Controller in a web app before and my tag cloud seems to think I've done some work in MVC recently.

If I had done that, it would have been quite a bit clearer. In the MVP patterns, there is a lot of synchronization and infrastructure code that is absent from MVC. The presenter and the view communicate back and forth a lot.

For example, consider a button click in an MVP web page. Being a nice, decoupled view, it would probably look like this:

protected void buttonFerment_Click( object sender, EventArgs e )
{
    _presenter.Ferment( );
}

That is, the view passes the request on to the specific presenter its wired up to. And the presenter in turn would do whatever it needs to, then go back to the view and ask it to update its UI.

Now let's see what the button click event would look like in an MVC page...

...except that you wouldn't actually see a click event in an MVC page. In fact, thinking back to the MVC projects I'm working on, the views don't even have code-behind files.

MVC seems to favour a purer separation of the View and Controller. From Jeremy's post above:

[In MVC, there] is typically little or no direct communication between the View and Controller.

Which is definitely not the case with the flavours of MVP. This also jibes with Chad Myers' explanation on Twitter.

It sounds like the MVP patterns are better suited for stateful environments (or stateless environments that someone has gone to great efforts to make appear stateful). MVC is shinier for stateless environments because the controller can collect up the model, dump it to the view, then call it a day. The view doesn't so much launch events as it does tell a front controller that it wants to do something. The front controller re-routes the request to whatever controller is supposed to do the actual work. (Thanks to Tom Opgenorth for helping me sort out that bit.)

Going back to my stock explanation of the differences, I said that the view was the entry point for the MVP patterns and the controller was for MVC. As I mentioned, this is accurate but it's a consequence of MVC having the front controller. Events in MVP are handled by the same page that launched them. In MVC, they are handled "globally" by the routing engine (aka. the front controller).

Finally, Bil Simser summed it up best when he said

Mvc lets me focus on the business problem and not how to update a view

So my ultimate understanding of the difference is that it is based on how intimate the View and Presenter/Controller are. In MVP, they are cosy and familiar, like cousins. In MVC, they are cold and distant, like lawyers.

Thank ye all for your kind attention while I worked this out in my head. If it has been helpful to anyone else, that's not my fault.

Kyle the Controlled Presenter

Quick note to announce that Hurricanes Hanna and Ike haven't dampened our resolve! BahaNET is meeting this Thursday, hopefully at the usual place but I haven't quite verified yet.

Discussion topic will be source control. Specifically, how to set it up, maintain it, and use it effectively. It's a topic that is often overlooked but can become very cumbersome very quickly when not done properly. I'd tell you war stories but I'm guessing I can't top yours.

There will also be some interesting side topics so if you're in the area, it'll be a good one to attend.

Hope to see you all there.

A moon or two ago, at the alt.net Canada conference, Tom Opgenorth convened a session on working without pants. And since Tropical Storm Hanna is turning out to be a non-event for me, I have some time to expand on this in blog-form.

The topic of conversation has come up a lot recently. In particular, a few people have asked for tips on landing remote contracts. There's also the aspect about how to work remotely once you've landed the job but that's been done. I've got a few posts on it myself at my old trailer. Mostly, it's a lot of common sense.

This is from the perspective of a consultant / contractor / someone paid by the hour who is tossed aside at the first sign of trouble. Some of it may apply to "permanent" positions but probably not.

Landing 100% remote contracts is hard

Landing contracts where you can work remotely 100% of the time right from the start is hard. In the five years I've been contracting, I've had exactly one contract where the consulting company didn't know me and the client didn't know me. Okay, that's not entirely true. The consulting company had worked with me before but got squeezed out after a month. While they were aware of my reputation at that point, they still hadn't worked too closely with me.

But even in that case, the consulting company had a technical lead on the project that was onsite. Everything was filtered through him. He assigned me tasks and I did them and sent him the code. He merged them into the main codebase somehow. As far as the client was concerned, they didn't even need to know I existed (though they did). Only at the very end, did they invite me up to help with the transition for a week.

It should be noted that by all accounts, this was probably the most successful project of my career. I don't mean to equate that to "remote developers == instant success". Only that my being remote definitely did *not* hinder the success. A year-ish later, when I talked with them again, they were very happy with the end product and I even did a small side project for them for a few months. I'm dancing around who the client was but now that I think about it, there's no need for secrecy. It was a SharePoint 2003 project for Marriott. Their main office in Maryland.

On-site up front

Other than that, I've worked on one other contract where I was remote from the start. My current one. Working for Devon Energy in Calgary. They agreed to it because I'm a known commodity. I've worked with them before in the recent past. And that first time was a model that seems to garner more support.

In two cases, I've started a contract on-site with no explicit expectations past the end of the contract. In both cases, I was very explicit that I was *not* staying in the country past the end of the specified date. And in both cases, I was able to extend, one for another year and the other for about five months. In the first case, I stayed on-site for six months, the second, for three.

This is just speculation but my reasoning is that companies are more amenable to this model. You're not as much an unknown to them by the end of the on-site period. They have a  sense of your abilities by then and have a gauge by which they can measure your offsite performance.

The major problem I have with this is the length of the on-site period. Three to six months is a long time to be away from your homebase. I was lucky in both cases in that it was in Calgary where I still own(ed) a house. And in one case, it coincided with my daughter's summer vacation. Without those two saving graces (such as they are), I don't know that it would be worth it.

As it is, I'm seriously reconsidering the maximum length of time I'd stay away from home at any given time. These days, it would probably be a month. My daughter's getting to an age where homework consists of more than "what are your feelings about orange?" And Mrs. Hillbilly isn't exactly the patient one in our humble clan.

In any case, this line of thought leads me to another option which, at this point, is still speculative

Trial period

With companies being so jittery, an option that I've been considering is one where I go onsite for a very brief period at a much reduced rate, say about half what I normally charge. Certainly enough to cover my expenses at least. After that, they can cancel with no questions asked or continue the extent of the contract.

The trial period would ideally be around two to three weeks. Some have raised concerns that that may not be enough time to get anything substantial done which is true. But there are ways you can try to counter that. One is simply being productive. Another is inertia. The idea that unless you're grossly incompetent, or incompetently gross, the company won't go through the headache of having to hire someone else.

But this leads to the major shortcoming. Many companies *will* see this as a headache and as such, will avoid it. That's the major stumbling block against any remote work, I think. There are so many unknowns involved in hiring someone, they don't want to add to them with someone who has a tendency to be offline sporadically during hurricane season.

But it's something banging around in the back of my mind for the next time I'm on the market. I also like it as a way to scope out possible landing points if we eventually leave the island. Whether or not I have any success with it is still to be seen.

Emergency contracts

The last model is another intriguing one. Just before I landed my current contract, I was approached by an agency that specializes in very short-term, quick availability, high-rate contracts. Like in the order of two-week to two-months. Companies lose a key resource or have a key demo, they fly you in, you work your magic, you go home.

This has some appeal in that presumably, I could work less. Because the companies are generally desperate, they pay premium rates. And your travel expenses are paid as well. Also, you get known to quite a few more companies who will remember you the next time they need someone in a pinch, or even more long term.

On the downsite, there is still the travel aspect of it. As I mentioned, I'm trying to minimize this.

Building an online presence

At the alt.net session, John Bristowe came up with an awesome point. If you want to focus on remote work, you need an online presence. Which is easier than skinnin' a possum these days. One of the ways he suggested this is simply to be online. Whether that be e-mail, IM, cell phone, LinkedIn, Twitter, a string and two cans, live streaming a la The Truman Show, whatever. Make sure people can contact you at all (reasonable) times. And remember that "reasonable" depends on your client's timezone more than it does yours.

I think Doc List does an awesome job of this. His web page is more than the usual blog and About Me page. It shows not only his services, past clients, and contact info but stories, musings, and even a reading list (and his thoughts on each book). In short, you'd be hard-pressed not to get a sense of Doc from his website. This is a guy set up for remote work. By comparison, I did a whois lookup for kylebaley.com the other day and was indignant that it wasn't available until I learned that I was the owner.

Conclusion

Closing point: I talked from the perspective of someone hoping to work 100% remotely for long periods of time. A more common alternative is one where you work onsite a couple days a week and offsite the rest of the time. This is probably the ideal scenario as you get most of the benefits of working from home, but still the necessary facetime one or two days a week to ease your client's mind. Obviously, this works only if you live in close proximity of the client.

This should be obvious but I'm talking only from personal experience here. If it applies in the more general case, that's not my fault.

Would love if people could share their tips for landing and maintaining remote contracts in the comments. I kind of have a vested interest in the topic.

Kyle the Distant