mattiask

I actually think pair programming cons/benefits is part of a larger pattern that I call "management overhead". The premise is any practice implemented to increase general quality risk being offset by decreased productivity of the top performers.

If you have skilled developers they will work more efficiently the less "management overhead" that is put upon them (processes, checklists, methodologies etc). They will simply self-regulate and a large amount of output of high quality. As the skill/experience of the developers in an organization drops management typically implements practices to better ensure quality. While providing checks and balances for the lowest denominator these will also typically slow down the best.

This is especially nefarious when you consider that a "great" programmer can be 10x (or more) as efficient as an average one. That's probably because they developed habits that make them so, and now you risk meddling with those habits. Making a 10x as efficient programmer 20% less productive can be costly.

The most insidious thing about this as top performers typically can stomach only so much "crap" that slow them down before leaving for another job. Which leaves the organisation with even less skilled workers that need even more "overhead" to control which in turn results in even more "good" employees leaving. Iterate a couple of years and you have an organization where it is very hard to do anything wrong but also almost impossible to get anything done because of all the committee's, best practices, etc

Of course pair programming is going to slow the best programmers down without adding much benefit. On the other hand for bad to average programmers pair programming will probably result in better code with will offset the reduced efficiency. From an organizational standpoint pair programming will reduce dependency on any one programmer.

It's up to every company to decide which trade-offs they're willing to make and balance that against the kind of employee's they have. Some lightweight practices might actually be beneficial even for the top performers but they do take some serious consideration to get right.

If you can manage it, hire really good developers and get out of their way.

I can only sympathize, I'm on the end of a 3-year product development cycle myself and it hasn't always been easy.

Some tips from my own experience:

1. Focus more on all the positive things that will happen when you succeed than thinking of all the bad things that will happen if you dont. It's easy to imagine all kinds of worst case scenarios, especially when your plagued by a a little doubt. Try to have faith and power through

2. Exercise! Trite as it might sound exercise is really important for mental well being and can lift your spirits if you're feeling down

3. Surround yourself with people that give you energy. Now I'm not saying you should only socialize with sycophants and yay-sayers but some people can be a real drain on a persons motivation.

4. Embrace "the fear". So things are hard, you're not sure you going succeed. On the other hand, you can probably look back at similar times in your life which now seems like exciting learning experiences. Realize that you're in the middle of one of those and chose be excited about it.

4. Don't let other people bring you down. Those who says it can't be done should get out of the way of those who are doing it. Some good ideas are only evident in hindsight so don't listen too much to the naysayers.

5. Get some perspective, even if things can seem bad and insurmountable I'm sure we all can imagine people who do everything for the same oppurtunity or people with far worse problems.

6. Adopt an attitude of every mistake being an learning opportunity. Don't be angry at yourself for making them. Be glad that it didn't take you longer to find out your mistake and glad that youre wiser for it

Because giving out equity leads you down a path to going public? Not everyone wants to go public if you rather enjoy running your company as you see fit and just having fun doing it.

I have a pet theory that there are what I would say "right-brain coders" and "left-brain coders". Left-brain coders are the typically geeks who love math, engineering, algorithms etc. They can be extremely good at digging down on some particular piece of code, optimize it or write some algorithm for it. They do not however necessarily excel at things like overall architecture or coming up with novel solutions.

The right-brainers are more the creative types which would typically be more interested in areas like art, design or writing but has found themselves into coding. They do not necessarily like math, algorithms etc but are great at identifying greater patterns, overall architecture or thinking "out of the box"

No one is typically one or the other but people tend to be on a spectrum somewhere between, although programming tends to attract more left-brainers than right-brainers.

From what I gathered Truecrypt provides plausible deniability through hidden volumes that appear to be random data. AFAIK it doesn't allow you to have a partition that when you decrypt with a certain password transforms to alternate content. So if the feds know you have something encrypted you might be in trouble.

What you want to do is to have a password that decrypts the content to something innocently looking. If the encryption program has the feature to both "dual encrypt" and do an ordinary encryption it should be hard to prove anything :) Not sure how you go about doing that algorithmically though so it would resist reverse engineering the program

This is why scientists don't get invited to cocktail parties

I've found that it works well even with programming. Braindump code to get things working as quickly as possibly, then refactor mercilessly. Stephen Kings "On Writing" is pretty good read in general and useful not only for fiction but other writing and the creative process as well.

For anyone who writes (and these days who doesn't?) I highly recommend the classic "Elements of Style" by William Strunk. If you only read one book about writing this should be it.

http://www.bartleby.com/141/

Btw, I think it's more efficent to first write a "braindump" and then start editing, rather than reiterating a sentence a time. You'll remove and rework a lot of what you write but it's easier to get in the flow and just "get things done" before you start rewriting it.

Well, the ball could in theory feel how much pressure you excert on it and where, and provide haptic feedback. In a super advanced scenarion perhaps the ball could provide feedback by varying it's firmness. Guess it depends on how advanced technology is how good the thimble solution could be, but it strikes me easier to manipulate a ball, which you could do even when it's in a suit pocket than to do gestures in the air. Some gestures might be doable though. I have a hard time coming up with a "Cursor" scenario for that solution though and tactility makes it so much more easy to control. Maybe if you used your fingers against a hard surface but that would limit it's flexibility.

Well, it wouldn't be a solid ball since it would have to be able to be squeezed so if dropped it atleast shouldn't roll away, and contrary to most smartphones it would actually be able to handle being dropped quite well. Rings/camera/gestures (minority report) in general are of course interesting but I think the downside of that approach is no tactile feedback

Oki doki, so given plausible future technology let's try to brainstorm a solution that addresses the issue of tactility in interaction, I give you the ... drumroll KinBall (Kinectic ball). The Kinball would essentially be a wireless ball, like a small juggling sack (the smaller ones) that you could interact with to control devices.

So the Kinball would have the following features

* Gyroscope/acceleratometer so it knows which side is up and how fast it's being moved and where it is.

* Sensors so it can feel where it's being squeezed/pressed and how hard

* Some kind of detecting mechanism for when two balls (cough) are touching each other. * Ability to vibrate in different frequencies and also only partially on different parts of the ball

So with a device like that you now would have to come up with a gesture language, some ideas

* If the future allows it, ability to change color

* Holding the ball and moving the thumb over it is "cursor mode, pressing in that mode would be clicking (and you could "click" and hold for submenus )

* Similarily swiping your tumb over the ball would be the swipe gesture

* Pinch-squeeze could be a specific gesture, perhaps combined with a gesture (like spritzing cookies :)

* If you hold the ball in the whole hand and move it from your chest and forward you could simulate resistance by varying the frequency of the vibrating to "feel" interface element

* you could roll the ball in your hand forwards and backwards, for instance for scrolling

* Double the balls, double the fun. With two balls you could perhaps do interesting things with the distance between them and again simulate resistance by vibrating the balls as you bring them closer to each other

* Social balling, you could touch someone elses ball (ahem) to transfer info, files etc

* You could have the ball on your desk and it could change color or pulse in different colors for different notifications.

This kind of interface would have some interesting features. You get tactile feedback and most gestures are pretty natural. You don't have to get smudge marks on your screens. The ball is pretty discrete and hardly visible in your hand. Heck with a headset (for getting information, like reading smss) you could just get away with a ball and the headset and skip the device altogether for some scenarios.

On the other hand it's another accessory you can lose and a ball in your pants might not be the best form factor.

Anyways, if Apple introduces the iBall you know where you read it first

Hi, I've been where you've been. From early programmerhood I've lived on a steady diet on coca-cola, pizza, crisps and other fast food. It was by no means an extreme diet and probably more healthy than an "all-in programmers diet" Even though the diet was pretty unhealthy I still maintained my weight in my early 20-something years.

When I was 30 my weight ballooned into the overweight area, and this was even when I was doing plenty of exercise. I started experimenting with different diets, wanting to find something that I could actually enjoy, didn't leave me hungry and didn't require preparation. Some diets worked health-wise but was too complicated and too boring, I've finally managed to find a diet that suits me, it might not be the one that suits you but I thought I mention it anyway.

The first thing you need to do is to stop eating sugar and that includes any High fructose Cornsyrup. I stopped having sugars in my coffee and eventually got used to it. Soda's was harder, I've eventually learned to enjoy carbonated water with meals and drink coffee and tea for programming fuel (A habit I plan to experiment with dropping)

The next thing is to cut out any fried food. It's a no-brainer since it's easily one of the most unhealthy things you can eat. Not so much for the fat content (which weirdly isn't as unhealthy as you think) but because fried food is loaded with carbohydrates.

Next you need to find a plan for what you actually should eat. I tried to find fast food alternatives that I could enjoy but that was more healthy, things like wook, thai food and sushi. It'll be a bit more expensive but you'll save lots of money from not drinking soda/candy and other crappy snacks

Eating out all the time is boring and expensive however, and the food isn't always that good so you need something healthy you can cook at home. My rule is to build meals around a quality protein (fish/beef/chicken) and have that with a vegetable that provides carbohydrates. Lenses, spinach and beans are especially good. Mix that with some other vegetables, spices and a non-carb sauce (ie bernaise) and you have a very nice healthy meal for the same price as eating out that you can prepare in 3 minutes. Hamburger patties isn't as healthy but since they're easy and probably more healthy than the alternative feel free to endulge.

Yeah, and no bread, rice, pasta, grain, potates, candy, fruit juice, cereals either if you can manage.

Eat eggs for breakfast, like 3 eggs in an omelett with some sallad and an avocado

The really good thing about this diet in contrast to other I've tried is that I'm not hungry, the cravings for sweets and snacks has essentially dissappeared and I need less portions of stuff.

This might sound extreme and I don't recommend you do everything at once. Start shifting parts of your diet and se what works, try having some of these meals and see if you like it.

Finding a diet that fits one taste and lifestyle is a continous process so take it one step at a time.

I think my diet pretty closely follows the Paleo Diet (though I don't really subscribe to all of it). A really good book to read is Why We Get Fat: And What to Do About It by Steve Taub

In my opinion taglines are a bit overrated. It seems like something you "have" to be like the big boys and brand yourself properly. The problem is that taglines tend say very little, "Love what you do" is a great motto to live by but does it tell me anything about your company, no. At worst you get enterprisy taglines like "pursuing synergestic excellence". I think companies, like people, should show who they are through their actions rather than telling others who they are. Also, when you create a tagline you kinda limit yourself to "being" that, while if you actually do excellent things your brand will contain a host of different positive aspects. The only proper uses of taglines I can think of is products where the tagline is descriptive in a way that the customer "gets" what they're about

Am I the only one freaked out by this passage? Wasn't this like the opening scene from the "The Mumy"?

"The panel managed to open the sixth vault but found an iron wall inside it, reports the BBC. The sixth vault has a snake on the front door and quoting an unnamed royal family source, it reports that opening it "might be a bad omen." The Guardian reports that the sixth vault has "special locks" but experts should be able to examine them and open it by Friday."

It sounds like a good technique if you have trouble focusing and feel unmotivated. However it feels like a lousy technique if you are :) When you're in flow-mode you don't want to have some stupid clock disturb your concentration every 25 minutes. You want to look down at your watch and go "whoops, I've spent 6 hours coding"

I was wondering something similar but for countries. Say that I work for my own company developing iphone apps or something like that. Now I like to travel around so I go to the US and work from there, could it be problematic?

You know being an introvert or extrovert isn't a binary thing but rather a spectrum. If you want to find out how you are on that scale you can get do a Myers-Briggs personality test to get a rough estimate.

I'm squarely in the middle myself, I enjoy being by myself for periods of time working on my own stuff but after a while I need to socialize, and when I've socialized I need some me-time again :)

I just hope people think they're introverted because they lack social skills, being uncomfortable and not enjoying certain social situations doesn't mean one is introverted it only means one has to improve one's social skills.

They're like any skill, something you learn by experience and practice. Perhaps the reason that people think many computer-oriented people are introverted is because they choose to spend time in front of their computer instead of interacting with people (irl) and therefore don't develop their social skills as much.

also known as "No Ping"

I think one of the big issues that needs to be tackled for the next generation of languages is inherent support for concurrency and orchestration of concurrency. Typically multithreading is something you have to explicit program into your solutions and make a trade-of between performance and thread-safety. It would be neat if a langugage could be designed with concurrency supported by default, with as small hit to performance as possible for simple scenarios.

There are some languages that provide some inherent support already, primarily functional languages (haskell, f#). Some more tradional languages have started tacking on features to better handle parallelization/concurrency, for instance C# with async,plinq, parallel.net etc.

I'm a bit doubtful however that everyone is going to switch to a functional language, I think the mainstream will stay with a object-oriented language. But there should be an oppurtunity to design a new object-oriented language from the bottom up for paralllization and concurrency which tries to solve performance issues with locking/collections etc on a lower level but provider higher level of abstraction.

Another issue that perhaps should be addressed is better support for "huge" data. In most cases with todays programming languages you have to type your integers, meaning you have to chose between an int, long, bigint or whatnot. and if you type something as bigint for instance all instances takes up loads of memory even if the span of the integer isn't that big. Why cant a number simply adapt to how it's used. I realize the underlying problems of the cpu and precision but still, it should be possible with a more elegant solution.

Being bored is certainly a big reason for procrastination, when you know exactly what needs to be done and it's just a matter of putting keystrokes to the keyboard I tend not to be terribly motivated (a trick for these cases is to trick yourself by having an interesting podcast or video on in the background)

Another big reason however I've found is being in a state of "overwhelm", when you have a too large array of problems and tasks it can easily led to procrastination since the problem seems insurmountable. The only recipe for this I've found is to concentrate on a small aspect of the problem/solution and start there, then start on the next and so on

Opera pretty much has this with it's new tab stacks. I think Firefox panorama is a bit of a misconceived concept where they've gone more for what's "cool" than practical.

The idea with panorama is that the browser is like your desktop and gives you the tool to setup and arrange it like one. But the browser isnt the desktop and there's seldom need for such persistent configurations of browser windows. Furthermore panorama feels one step too removed where you have to go into the panorama view to change group.

Opera's tab stacks feels much more natural and immediate, simply drop tabs you want to group, for instance, a "to read stack" and you can switch to it and it's browser windows immediately. Also pinned tabs are great for putting common windows to the far left, showing only the favicon and preventing it from closing

Of all the ways for humanity to go out, that would be one of the cooler, not with a whimper but with bang! :)

I hope "exceptional object in our cosmic neighborhood" doesn't mean "big astereoid coming our way" ;)

To code quickly you should just code quickly. To code difficult stuff lying on the sofa or talking a walk is an excellent way to "meditate" on a solution. If you think through a problem that way the ensuing coding will be quicker and better and save you some trial and error.

It's too bad that most workplaces arent conducive to that kind of workprocess (try lying in a sofa at work and not be called a slacker :)

I don't agree with one the points and I think at least one important is omitted. You don't need to know any scripting language and while Ruby, Python etc is popular in the LAMP camp .Net (and possibly Java) and probably a dussin other compiled languages are holding their own. There's nothing intrinsically elegant or better with scripting languages.

One major trend that's omitted is the coming important of concurrent/multicore programming. It has become clear for many that computers aren't getting that much faster but they're getting more and more core's. To be be able to utilize that power you need to start code from the ground up to take advantage of multithreading.

On the .Net side Microsoft seems very aware of this and has rolled out a number of new techologies and tool support, things like Parallel.net, PLINQ, Reactive Framework and most recently Async. F# is by nature of being a functional language very suited for parallel processing.

No doubt other frameworks and languages will soon follow.

Browsers are going mainsteam and it spells bad news for the browser vendors and good news for the users. All browers nowadays pretty much look the same, have the same performance and try desperately to distinguish themselves with surrounding features.

The basic problem is that the browser is still "trapped in a sandbox", ie they're trying to become the OS but they're still just an application running in a limited context. If all browsers looks the same and perform the same it's going to be real difficult to differentiate yourself from the competion.

It makes sense from big guys point of view. Apple, Microsoft and Google must be present in the browser space to be competitive, especially google whose strategive agenda involves moving application from the OS to the web. For Firefox and Opera things look a bit more bleak IMO.

I think browsers will be commoditized to the degree it will be very difficult to compete, it will all come down to brand awareness and surrounding features.

My hunch is that Firefox and Opera is dying a slow death and will be irrelevant within 3 years.

The release early and release often is an often repeated mantra, the problem is that it's only about half true and mostly misunderstood.

The reason for releasing early is often stated as that the user feedback will guide your product and design. The problem is that user-driven development is a crapshot, as Henrik Ford famously being quoted: "If I'd given people what they asked for I'd built a faster horse".

The core idea of your product needs to be in place and well implemented when you release, you don't need all the features but first impressions do matter. The main reason for releasing early is that most people can't recognize a good idea so it's better to release early than toil on some idea for years before realizing that you're the only one finding it useful

First mover advantage is highly overrated, after all, apple didn't build the first touch-screen smartphone, they simply built the "first" one offering a great experience.

So find a balance between polish, features and time to release, don't just release something half crappy to see how people react. The road to success is paved by ideas that were basically good but were implemented poorly and then discarded before given another chance.

What is the purpose? If you do it on twitter you lose lot's of stuff that makes stackoverflow good: reputation, voting, a competent userbase etc.

What you want probably is a notification when someone anwers a question. If email isnt' fast enough build your own notification system using their API

Well, there's two sides to that coin. By having the client pay hourly you put the "risk" of the project on his shoulders, but you also limit yourself to earning only a hourly rate. Why is that bad? An experienced programmer might accomplish a task/project quickly due to having done similar projects and have an arsenal of code/examples/tools at his disposal. An experienced programmer might be able to get 20%-30% markup on his hourly fee but he might finish the project five times as fast as another less experienced programmer might.

You won't be able to leverage your gray hairs and the time they save you as efficiently with an hourly fee.

If the project is well-defined you might be tempted to accept a fixed price and crank it out quickly which will net you more money per hour. I'd advice holding of atleast a week even if you do it in a day or two or the customer will start questioning your price ;)

If the project/customer is fast and loose with the spec and functionality (as most projects are) you're in dangerous terroritory where constant changes keeps eating away at your time.

If you can get a high hourly fee and the project is fuzzy, go for it, meetings and stuff like that will earn you a bunch anyways.

Another strategy is to split the project into discrete parts and charge a fixed price for each (negotiating each one), that way it's easier to define the scope of the project and it eliminates risk both ways. It also gives you and the customer have a chance to get to know each other before committing to the project and helps avoid being in the clutches of a psychopath customer.