I’ll just go ahead and proclaim myself the King of Craigslist until somebody else steps forward. I think I did more business than any single person last year. (By the way, freelance programmers, try Ben’s Gigs – shameless plug!).
This article is about how to find good help with your project.
Continue reading »
What to get what you want, more often? Well me first and me too. Just kidding 
I have some ideas.
There is a famous book called Seven Habits of Highly Effective People. Here is a short summary of what the book covers.
Briefly, here are the habits:
1. Be proactive
2. Begin with the end in mind
3. Put first things first
4. Seek first to understand, then to be understood
5. Think win-win
6. Synergize
7. Sharpen the saw
It’s really hard to argue with any of these. But I can augment and enhance them.
2. In today’s software and web development world, there is no “end” per se. What is important is that you have a specific way to test, in positive terms, exactly what you want to do. I see a lot of people stumble when it comes time to define exactly what they want. What they really want, no kidding aside, is to be happy. But that concept is very slippery and it can change faster than you think. Just today, someone accused me of being a common thief. But if you look at the project history, it’s easy to verify that things got done just as agreed. The only thing I didn’t deliver was happiness, which of course isn’t something I can promise to anyone. We forget that the things we do don’t guarantee happiness.
5. The power of win-win is that it gets you thinking about what the other person wants. The other person doesn’t really care about whether you win or lose, as long as they win. So by thinking win-win, it puts you in that important understanding-seeking mode while looking out for yourself at the same time.
6. I have yet to see synergy work in the wild. Have you? Send your stories and comments below!
Here are some thoughts on how to get your web developer to understand you better.
I spend a lot of time thinking about how to be a better communicator. I think I’m pretty clear, and I wish everyone else would just try harder But alas, it’s up to me to make sure my message is understood. So here are some things I think about:
1. Use fewer words. Is there a shorter way to say it? Say it that way. I can’t prove it, but I have a notion that there is a signal-to-noise ratio in language too. An excess of words, or alternate phrasings, or variation makes it harder to understand. I know that educators recommend saying something three different ways (I’m making that up), but I feel like silence is another effective way to punctuate or underscore the importance of a point. If you just keep running on like I have in this paragraph, people will forget what you’re talking about. Do you remember yet that I was talking about using fewer words?
2. Consider high bandwidth communication mediums. Phone or in-person is best. Texting is worst. Between those poles lie video chat, email, tweeting, etc. Just consider that the amount of information relayed through a real-time phone call is very rich. It allows for a conversation. Have you noticed that voice mails are sometimes hard to comprehend? Many times, I find myself calling people back because, although I heard their voice mail, I didn’t really comprehend the message. Something about a real-time conversation changes that. Voice mail, email, twitter, Facebook, and snail mail are all asynchronous. Handy for exchanging hard data, but terrible for conveying complex concepts.
3. Assume people are trying their hardest. I think this is key to understanding and being understood. I’ve learned that the vast majority of people are trying their hardest to balance all the challenges in their lives. Yelling louder or pounding the table may get what seems like a temporary result, but a better approach is to….oh my god, flashback, I just remembered one of the Seven Habits of Highly Effective People: “Seek first to understand, then to be understood.” Wow. There is a lot of meaning in that statement for me, especially since I just invented it again. You may get what seems like a temporary win from table pounding, but a better approach is to understand the complex challenges your listener faces and, through that understanding, build trust that your message will help their lives. Then they are ready to receive.
I don’t know; I try to do that with this blog. I hope someone likes it!
Let’s see how many of the 7 Habits I remember without looking them up:
1. Put first things first
2. Seek first to understand, then to be understood
3. Sharpen the saw
4. ….
Yup. Well I hope those were the important ones. Here’s the real list:
1. Be proactive
2. Begin with the end in mind
3. Put first things first
4. Seek first to understand, then to be understood
5. Think win-win
6. Synergize
7. Sharpen the saw
I think I’m going to make some notes on these and post it separately.
I just had a little insight about the CMS world that I wanted to share with you.
Whether you’re on WordPress, Drupal, Magento, DotNetNuke, Joomla, Mambo, or some other CMS, they all have a few basic concepts covered.
1. Themes – the idea that one look/feel should be easy to replace with a different one. Each CMS has their own incompatible approach to themes, but all themes within a single CMS are supposed to be substitutable with one another.
2. Static Content – here, we’re talking about stuff that the admin can log in and edit. Contact information. Frequently asked questions. Company history. Each CMS solves this differently, but the result is fairly uniform: you get a menu item in the navigation that leads to a page of content that you can edit from the administrative interface.
Most CMS’s are approaching theming and look/feel as a ‘all or nothing’ approach, where you just choose the template that suits you best. Customization and polish beyond that requires a programmer to hack into the template code and make tweaks by hand. They do it this way because templates must support specific constructs and features in order to be substitutable with one another. Once you start customizing a template, you run the risk of making it difficult to swap it out later. A lot of people prefer to retain that capability in case they find a nicer looking template down the road. Other people choose to commit to a single template and customize it to such an extent that it could never be replaced by another without a lot of additional effort and rework.
So what’s the best approach for you? Really great question, let’s talk In general, I recommend erring on the side of having a theme that’s too generic but compatible rather than a theme that’s highly custom but slick looking. There are other approaches to development, but the programmer in me wants to see you say with ‘stock’ options as long as possible. The artist in me says “Nay! Be pure and brave! Build from scratch and make it better than the world has ever seen!”
I like both ideas. What’s right for you?
Here’s a thought model that might help you get a better feel for how I understand and evaluate complexity. If you ever find yourself worrying that you might understand your business so well that it’s hard to explain to others, this might also put those concerns to rest.
I hope I don’t offend anyone by posting this. I think it’s small enough that you can’t really make out the details anyway.
This is an example of a real database. Let’s suppose it’s your web site.
This is what we call existing code. Someone else has written it; someone else thought it through; it makes sense to someone else, but that person it’s around anymore. You’ve just hired me. Understandably, you want to be impressed with great price, great speed, and great quality. You want to be wowed. But what is great value? Our definitions of “wow” will be very different if I see complexity differently.
The human brain has surprisingly strict limitations on the amount of information it can process, and there is very little variation between “smart” people and “stupid” people. While raw memory may not vary that much, problem solving approaches vary greatly. Not all men are created equal where complexity is approached, contained, and processed.
I know how to handle complexity. Sometimes it can be ignored, sometimes it can’t. For example, if I know a certain task is going to land me squarely in the middle of this database, I will be reluctant to avoid understanding the database up front. If I’m creating something for you that never touches this database, I’m more likely to be comfortable advising you that it’s okay to ignore it and move forward at full speed. I understand the danger of over-simplifying something that is obviously complex but not yet understood. You need someone who knows the difference.
Let’s suppose you know your business well, and you think this database makes perfect sense. I, being new, will certainly disagree. Where do we go from here? Our choices are not great:
A) Make risky choices for a temporary wow effect
B) Take the time to really understand what is going on, and forego any hope of an immediate wow
These aren’t great choices. A is no good for me, and B is no good for you.
At the end of the day, I may need to pass on this project. Part of my job is to provide you with the necessary and consistent resistance required for you to make good, informed choices. You can’t do that with someone who resists but eventually caves in their supposed area of expertise. What if your heart had a pinhole rupture, and you knew it? And what if you found a doctor who correctly diagnosed it? Now – and imagine with me here – what if you were able to talk the doctor out of his diagnosis? You could never trust that man. He’s not confident enough in his talent.
This database diagram came from a real client. I truly believe that the client understands the complexity, and I think he knows that there is no shortcut. But he’s searching for one anyway. My job is to withstand the test.
I’ll let you know how it goes
Do you ever get the feeling that people are making web development a lot more complicated than it needs to be? I have something to make you feel better.
Today, I was alarmed to learn that the universe was much larger than I had imagined. This is going to sound funny to a lot of you, but I’m not afraid to admit ignorance:
1. I assumed our galaxy (The Milky Way) had thousands of stars because I could see them. It has billions.
2. I assumed that streak in the sky, ‘The Milky Way’, was a bunch of star-like dust or whatever; not really stars. It’s all stars – the visible part of a solid core of stars – and we’re staring right into the center of our galaxy.
3. I assumed the all the “real” stars I was seeing were just kind of ‘in space’. I suppose in a sense, I forgot about galaxies. I thought it ended with the stars I could see.
4. I assumed there were perhaps a couple other galaxies, like Andromeda. There are billions.
I didn’t really ever think about how it all fit together. I was just walking through life comfortable with what I imagined. It fit well enough with my model of reality. Ignorance is truly bliss. My mental model of reality was working fine; I was happy. The size of the universe worked well for me, and I didn’t have any reason to suspect anything else. I recognized my version of the universe as complex, but my version was huge orders of magnitude less complex than it really is.
The point is, none of these assumptions make any sense or hold up under analysis. If I had stopped to think it through, just a little education would have caused me to realize the error in my thinking.
So naturally, I panicked. How far did I need to tear down my understanding of reality before I could get on the right track again? Here are some realizations:
1. Forget light speed travel. We can’t even get out of our own galaxy at that speed. 10 times light speed wouldn’t help. We need to completely re-think the idea of travel and universe exploration.
2. Even if we could go fast enough, the idea of a little bubble of air traveling those vast distances seems impossibly precarious. There must be entire galaxies exploding out there. By probability alone, it seems our bubble would be burst.
3. Intelligent life. I can’t decide; on one hand, it seems very probable given that there are trillions of stars. On the other hand, life exists in such a narrow and delicate band of conditions that it may be much less probable than the numbers reveal on the surface. In any case, there is nobody close by.
So this brings me full circle to you, and web sites, and the Internet in general. Here is an article that talks about IPv6, an extension of a basic Internet protocol in reaction to the ever-expanding need to transfer data.
Suppose the Internet is the universe (it is for web sites). Do you know how big it is? Do you even have something to compare it to? And what about all the diversity that exists in the Internet? Blogs, social networks, videos, still images, audio, apps, web sites, APIs, protocols, text, SEO, languages, databases, XML, machine code formats. Do you understand all of that stuff? If you treat the Internet like I treat the universe, you haven’t even sat down to think about it. And now that you sitting and thinking about it, questions are starting to come up. Your simple assumptions aren’t fitting as nicely as you thought. Web sites are quite a bit more complicated than you imagined in your simple model of things.
As a web site user or Internet user, you’re like me with the universe: a user. No need to understand the details. But when you cross that threshold and become a creator, suddenly the details are important and things get complicated quickly!
I’m your experienced traveler of the Internet universe. Welcome aboard. Just don’t ask me about theoretical physics.
I’m building PrestoScript in Ruby and the more I get into it, the less I am in anyone’s framework but my own. Why is that? Is there a certain class of problems that are frameworkless? I’ve been thinking lately that generalized frameworks could be a farce. I always explain to clients that Ruby on Rails is streamlined toward building data-backed web applications. I stress that all you can really do with technology is optimize it toward a certain problem domain; you can’t really invent anything new (or rarely).
So the deeper I get into my problem domain, the less I like any framework except what evolves naturally from starting with a nice Turing-complete language like Ruby or Lisp. I probably sound a little like Paul Graham now, but the guy has a point: if you roll it yourself, you end up with something that fits the problem domain perfectly. That includes all the exceptions and random rules of life and departures from theory that you end up discovering along the way.
To those who cite the productivity gained from sticking with widespread or standardized frameworks as reason not to venture off the path, I might counter that any problem solved purely within an existing framework is not worth solving. In other words, yes, you can make a great web app with Ruby on Rails, powered by ActiveRecord backed by mySQL. But within that class of problems, what value are you adding? Ruby on Rails came from the Basecamp framework I think. They rolled their own starting from pure Ruby. The Rails community will continue walking the fine line between general utility and optimal solution, but in a bigger sense they’re just swirling around in the same toilet bowl with all the other turds.
When I get far enough into a problem, I find myself spending as much time fitting various “frameworks” together than it would take me to write something from scratch that fits perfectly, is optimal, and perhaps most importantly, makes me feel like I accomplished something good with my time.
I run the “surgeon” model of development: an expert and one or more assistants.
The first place I read about the surgeon model was in Fred Brooks’ book, Mythical Man Month. In it, he describes a configuration where one expert uses several assistants. The expert tends to ambiguity: high-level crafting, planning, and architecture. The assistants tend to tasks which are important but well defined.
erlang is a programming language that is supposed to be very scalable. It encourages a form of design that is naturally scalable and as such requires some degree of adjustment for many programmers. The whole idea doesn’t sit well with me.
I tripped across this link the other day. It describes my thinking about software design:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
