- Joel on Software - Incentive Pay Considered Harmful
- Why Individual Measurement is Bad
- Fog Creek Compensation
- Badge of Merit
- Microsoft's 3.0
Flickr Badge
Wednesday, August 10, 2005
Links related to the previous two posts
I just ran into these links which are related to the previous two posts:
Tuesday, August 09, 2005
Skill based promotions
I wrote mentioned a skill based promotion system in my essay yesterday. I've fleshed it out a bit more. Here is my current thinking on this topic.
When deciding whether to promote somebody, ignore past performance. This sounds like a radical idea, but it's not.
A promotion usually signifies some change in role. The best person for a project management role is not always the best programmer in the team. Past performance shows that they have the skills to do well in their current role. What is important is that the person has the skills required to perform well in the new role.
Instead, consider a skill based promotion. Establish the skills required for different roles in the organisation. Promote people when they acquire those skills.
Such a system is also transparent: Everyone knows where they stand and what they need to do to achieve a promotion.
Here is a plan on how to implement skill based promotions -
How can we come up with a list of skills? Here is one example -
Developer
Key Skills Required -
Project Manager
Key Skills Required -
Once the lists of skills have been written down for various roles, the next step is to help your employees acquire it. There are three ways to do this -
For my views on these three points, see my previous posts on creating ad-hoc groups and modes of learning.
One problem with this method is that there are only about 2-3 different roles available in project development, and thus reduced scope for promotions. It will also take a long time to acquire all the required skills from scratch.
The solution is to create intermediate positions when a part of the skills have been acquired. For example the above list says that a developer needs 8 key skills. There could be an intermediate promotion when 3 skills have been acquired, and another one when 6 skills have been acquired. Here is an example of such a ladder:
And for Project Manager:
The above are just examples, and should be tweaked as required.
In my opinion, such a skill based promotion system is superior to a performance based promotion system.
This post is a part of the selected archive.
When deciding whether to promote somebody, ignore past performance. This sounds like a radical idea, but it's not.
A promotion usually signifies some change in role. The best person for a project management role is not always the best programmer in the team. Past performance shows that they have the skills to do well in their current role. What is important is that the person has the skills required to perform well in the new role.
Instead, consider a skill based promotion. Establish the skills required for different roles in the organisation. Promote people when they acquire those skills.
Such a system is also transparent: Everyone knows where they stand and what they need to do to achieve a promotion.
Here is a plan on how to implement skill based promotions -
- Write down a list of skills required for each role - apart from promotions, these lists of skills will also help in hiring
- Provide resources to enable employees to acquire those skills
- Promote them when they have acquired the relevant skills
How can we come up with a list of skills? Here is one example -
Developer
Key Skills Required -
- Thorough knowledge of the programming language
- Refactoring
- Knowledge of a unit testing framework
- Project architecture and design skills
- Estimation methods
- Design patterns
- Understanding of algorithms
- Code reading skills
Project Manager
Key Skills Required -
- Identifying and managing project risks
- Estimation methods, formal and informal
- People and communication skills
- Knowledge of at least one traditional process and one agile process
- General management skills
- Good technical knowledge to understand problems faced by the team (Although this is not strictly required, programmers do respect their managers a lot more if they are technically oriented)
- Some amount of domain knowledge
- Basic understanding of the target end user - this is needed because the project manager is the user advocate in the team
- Understanding of the technical environment - source control, testing methods used etc
Once the lists of skills have been written down for various roles, the next step is to help your employees acquire it. There are three ways to do this -
- Allowing them to attend seimnars, workshops and conferences
- Filling up the company library with relevant books and magazines
- Enabling them to form ad-hoc learning groups
For my views on these three points, see my previous posts on creating ad-hoc groups and modes of learning.
One problem with this method is that there are only about 2-3 different roles available in project development, and thus reduced scope for promotions. It will also take a long time to acquire all the required skills from scratch.
The solution is to create intermediate positions when a part of the skills have been acquired. For example the above list says that a developer needs 8 key skills. There could be an intermediate promotion when 3 skills have been acquired, and another one when 6 skills have been acquired. Here is an example of such a ladder:
- Developer [0/8 skills]
- Senior Developer [3/8 skills]
- Technical Designer [6/8 skills]
- Senior Technical Designer [8/8 skills]
And for Project Manager:
- Project Lead [5/9 skills]
- Project Manager [9/9 skills]
- Program Manager [9/9 skills + sucessful completion of at least two projects]
The above are just examples, and should be tweaked as required.
In my opinion, such a skill based promotion system is superior to a performance based promotion system.
This post is a part of the selected archive.
Monday, August 08, 2005
Merit Based Pay
Conventional wisdom tells us to take the top performers and reward them highly. The theory goes that if they aren't recognised and rewarded, they will soon leave to better opportunities elsewhere. Even if they don't leave, they will soon be demotivated and put in an effort comparable to the weaker performers. After all, the reward is going to be the same!
Conventional wisdom is wrong.
Do not reward the better programmers any more than the weaker programmers.
By rewarding better programmers, you place each individual in direct competition with the others. The easiest way to get to the top of the stack is to keep ones knowledge to oneself and stop helping others. Not surprisingly, a team can quickly fall apart. A quality team needs cooperation, not competition. Spread of knowledge benefits the entire team, and vastly increases the chances of delivering higher quality software.
The issue of competition and cooperation is a complex one, which deserves an essay on its own. In the meantime, consider the following extract from the book Peopleware:
If you haven't read Peopleware yet, do so. It's one of those books that will completely change your perspective on software development.
Besides, how do we find who the best performers are? Should we count lines of code written? What if someone provides an elegant solution that takes only half the number of lines of code. Are they less productive? Or should we look at bugs per hundred lines of code? Does that correlate with programmer quality? Or does it just encourage programmers to mark bugs as "Invalid" or "By design" instead of fixing it, so that it does not count against them? Every manager's dream is to have a simple metric that can be used to quantify the quality of the programmer. Unfortunately, there is still no easy way of measuring programmer quality.
In this ITCoversations interview, Joel Spolsky talks about a team member who didn't seem to do anything. However, every team he was in succeeded. It turns out that he spent most of his time teaching and mentoring the other team members so that they could do a better job. All his team members loved having him on the team, but management was on the verge of firing him because the performance metrics showed him as the weakest performer.
One thing is clear: Its hard to measure the value added by a programmer to the team, its hard to measure who the best programmers are, and even if you know who they are, its hard to come up with some method of rewarding them without heavy side effects. But what is the alternative?
Is it really practical to say that we will reward the best programmers as much as the worst? What about the best people leaving the company or getting demotivated? What happens to employee morale when they realise that even if they put in extra effort, they will not be rewarded any more than if they had put in their normal effort? Ahh, the complexities of the real world.
The best solution to this tricky situation is to ensure that you don't hire weak programmers. It's tempting to lower your standard when you desperately need programmers, but this can have serious long term implications.
Next, try to ensure that the key motivating factor for your employees is not a reward. People should want to put in an extra effort because they want to deliver quality software and see the project succeed, not because they want some reward. It's the project manager's responsibility to bring about this change of mindset.
Finally, have a clear and consistent promotion system. Promotions typically look at skills rather than performance. Establish the skills required to move up a level. Then promote people when they achieve that skill level. This provides a sense of progression without breaking up the team.
Some other solutions are provided by Mary Poppendieck in this excellent essay [PDF] for Better Software Magazine.
No matter which solution is adopted, managers must be careful. By attempting to optimize individual performance, they can end up sacrificing team performance. This is a risk that must always be kept in mind.
This post is a part of the selected archive.
Conventional wisdom is wrong.
Do not reward the better programmers any more than the weaker programmers.
By rewarding better programmers, you place each individual in direct competition with the others. The easiest way to get to the top of the stack is to keep ones knowledge to oneself and stop helping others. Not surprisingly, a team can quickly fall apart. A quality team needs cooperation, not competition. Spread of knowledge benefits the entire team, and vastly increases the chances of delivering higher quality software.
The issue of competition and cooperation is a complex one, which deserves an essay on its own. In the meantime, consider the following extract from the book Peopleware:
Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal. Here are some of the managerial actions that tend to produce teamicidal side effects:
- Annual salary or merit reviews
- Management by objectives (MBO)
- Praise of certain workers for extraordinary accomplishment
- Awards, prizes, bonuses tied to performance
- Performance measurement in almost any form
If you haven't read Peopleware yet, do so. It's one of those books that will completely change your perspective on software development.
Besides, how do we find who the best performers are? Should we count lines of code written? What if someone provides an elegant solution that takes only half the number of lines of code. Are they less productive? Or should we look at bugs per hundred lines of code? Does that correlate with programmer quality? Or does it just encourage programmers to mark bugs as "Invalid" or "By design" instead of fixing it, so that it does not count against them? Every manager's dream is to have a simple metric that can be used to quantify the quality of the programmer. Unfortunately, there is still no easy way of measuring programmer quality.
In this ITCoversations interview, Joel Spolsky talks about a team member who didn't seem to do anything. However, every team he was in succeeded. It turns out that he spent most of his time teaching and mentoring the other team members so that they could do a better job. All his team members loved having him on the team, but management was on the verge of firing him because the performance metrics showed him as the weakest performer.
One thing is clear: Its hard to measure the value added by a programmer to the team, its hard to measure who the best programmers are, and even if you know who they are, its hard to come up with some method of rewarding them without heavy side effects. But what is the alternative?
Is it really practical to say that we will reward the best programmers as much as the worst? What about the best people leaving the company or getting demotivated? What happens to employee morale when they realise that even if they put in extra effort, they will not be rewarded any more than if they had put in their normal effort? Ahh, the complexities of the real world.
The best solution to this tricky situation is to ensure that you don't hire weak programmers. It's tempting to lower your standard when you desperately need programmers, but this can have serious long term implications.
Next, try to ensure that the key motivating factor for your employees is not a reward. People should want to put in an extra effort because they want to deliver quality software and see the project succeed, not because they want some reward. It's the project manager's responsibility to bring about this change of mindset.
Finally, have a clear and consistent promotion system. Promotions typically look at skills rather than performance. Establish the skills required to move up a level. Then promote people when they achieve that skill level. This provides a sense of progression without breaking up the team.
Some other solutions are provided by Mary Poppendieck in this excellent essay [PDF] for Better Software Magazine.
No matter which solution is adopted, managers must be careful. By attempting to optimize individual performance, they can end up sacrificing team performance. This is a risk that must always be kept in mind.
This post is a part of the selected archive.
Saturday, August 06, 2005
Links to Agile Methodologies
Here are links to some other agile methodologies -
Friday, August 05, 2005
Strunk, William, Jr. 1918. The Elements of Style
I just went out and bought this book: Strunk, William, Jr. 1918. The Elements of Style
Tuesday, August 02, 2005
Source Insight
Source Insight is THE BEST code editor I've seen. It is totally, staggeringly, awesome. Especially if you are coding in C. It has pushed vim onto No.2 on my list now. It's way better than VC++. Much better than eclipse.
I've not used IntelliJ so I can't comment on that. I've heard a lot of good things about it, so if you are into Java programming you may want to investigate it along with Source Insight. But for C programming, it simply blows everything else away.
Now, VC++ and eclipse may have more features, but this still beats them. Why? It provides contextual information about whatever symbol is under the cursor. It makes navigating to different functions a snap. It can keep many, many files open at a time. And its FAST. Did I say FAST? I meant amazingly, blindingly FAST. Eclipse can barely run on my system, let alone allow me to keep twenty files open at a time. Source Insight lets me do it.
Did I mention smart rename? It allows me to rename a variable or function name, and it will rename the function everywhere its called. I know it's there in eclipse, but eclipse is such a slow behemoth that I just can't stand it.
Forget coding. Source Insight make READING code so easy. I can travel between various functions in seconds. I can see where all a function is called from. It formats the code beautifully. I can see function names and variable names so easily. They just pop out when you're looking for them.
Oh, and did I mention smart searching? Smart searching allows you to search symbols from the entire project. So you dont have to remember which file contains the function you want to see. What is more, you can type just a few characters of symbol to see it. That's available everywhere, right? Not when those characters can be from the middle of the function or variable name. Still, its been done in other IDEs. But not when its a similarity search, so you can search for "styleAdd" and it will find "displayAddStyleProperty". This is great when you don't know the exact name of the function but you have an idea that its got something to do with styles. This feature alone makes Source Insight more worthwhile than anything else.
Check out the trial version. You can download it here.
I don't use IDEs to read and write code anymore. I just use them for compiling and debugging. Source Insight actually makes me enjoy using it. This is how software should be written. It's awesome. I'm converted.
This post is a part of the selected archive.
I've not used IntelliJ so I can't comment on that. I've heard a lot of good things about it, so if you are into Java programming you may want to investigate it along with Source Insight. But for C programming, it simply blows everything else away.
Now, VC++ and eclipse may have more features, but this still beats them. Why? It provides contextual information about whatever symbol is under the cursor. It makes navigating to different functions a snap. It can keep many, many files open at a time. And its FAST. Did I say FAST? I meant amazingly, blindingly FAST. Eclipse can barely run on my system, let alone allow me to keep twenty files open at a time. Source Insight lets me do it.
Did I mention smart rename? It allows me to rename a variable or function name, and it will rename the function everywhere its called. I know it's there in eclipse, but eclipse is such a slow behemoth that I just can't stand it.
Forget coding. Source Insight make READING code so easy. I can travel between various functions in seconds. I can see where all a function is called from. It formats the code beautifully. I can see function names and variable names so easily. They just pop out when you're looking for them.
Oh, and did I mention smart searching? Smart searching allows you to search symbols from the entire project. So you dont have to remember which file contains the function you want to see. What is more, you can type just a few characters of symbol to see it. That's available everywhere, right? Not when those characters can be from the middle of the function or variable name. Still, its been done in other IDEs. But not when its a similarity search, so you can search for "styleAdd" and it will find "displayAddStyleProperty". This is great when you don't know the exact name of the function but you have an idea that its got something to do with styles. This feature alone makes Source Insight more worthwhile than anything else.
Check out the trial version. You can download it here.
I don't use IDEs to read and write code anymore. I just use them for compiling and debugging. Source Insight actually makes me enjoy using it. This is how software should be written. It's awesome. I'm converted.
This post is a part of the selected archive.
Friday, July 29, 2005
Index of learning styles
Tying in with my previous posts on learning styles, I just came across this page which has an index of learning styles. From the website:
The Index of Learning Styles is an on-line instrument used to assess preferences on four dimensions (active/reflective, sensing/intuitive, visual/verbal, and sequential/global) of a learning style model formulated by Richard M. Felder and Linda K. Silverman
Thursday, July 28, 2005
Wednesday, July 27, 2005
Ad hoc groups
Sachin posted an interesting comment about learning in companies.
One of the things I've noticed when talking to people is that most [Indian] companies do not take any steps to nurture adhoc groups. These are groups where like minded people can get together and talk or do side projects. Companies can create an environment where people can form such groups by themselves and then just sit back.
If you look at many of the US software companies (Google, MS etc) there is something there which causes people to do side projects and spread knowledge all the time. If one guy finds something cool, pretty soon there are a bunch of people discussing it.
Compare that with my experiences here. If anyone talks about some interesting topic, not connected with work, the reaction is something like "oh ok," rather than "cool, lets find out more about that." Or if someone decides to do something interesting, not connected with work, the first reaction is "whats the use" rather than "cool! lets do that this saturday".
Why is that? Is it that there are not many doer type people in Indian companies? Or is it because the company culture doesn't enable them to actually do anything? It is probably some combination of both I would think.
It's not like this in all companies of course (eg: Yahoo Bangalore), but its true in a depressingly large number of them.
What can be done about this?
This post is a part of the selected archive.
One of the things I've noticed when talking to people is that most [Indian] companies do not take any steps to nurture adhoc groups. These are groups where like minded people can get together and talk or do side projects. Companies can create an environment where people can form such groups by themselves and then just sit back.
If you look at many of the US software companies (Google, MS etc) there is something there which causes people to do side projects and spread knowledge all the time. If one guy finds something cool, pretty soon there are a bunch of people discussing it.
Compare that with my experiences here. If anyone talks about some interesting topic, not connected with work, the reaction is something like "oh ok," rather than "cool, lets find out more about that." Or if someone decides to do something interesting, not connected with work, the first reaction is "whats the use" rather than "cool! lets do that this saturday".
Why is that? Is it that there are not many doer type people in Indian companies? Or is it because the company culture doesn't enable them to actually do anything? It is probably some combination of both I would think.
It's not like this in all companies of course (eg: Yahoo Bangalore), but its true in a depressingly large number of them.
What can be done about this?
This post is a part of the selected archive.
Tuesday, July 26, 2005
The different modes of learning
I've been thinking about this topic a lot over the last couple of months. It is a topic that I'm figuring out with my team. I'm just going to throw it out and see what the feedback is like.
I’m going back to my college days for this the first part of this essay. What I want to discuss is the different modes of learning. This will probably come as no surprise to most of you: Different people learn through different means.
Some learn by listening. Remember people who just sat in class and absorbed the entire lecture ? They learnt by listening. Then there are those who learn by writing. They take notes. Some people learn by reading. They just sleep in all the clases, then go home, read the text book and ace the exam. Some learn by talking. They need to discuess the topic with someone else to clarify their thinking. Finally, we all know that student who could write great programs on the computer, but could barely follow what was going on in class. They learnt by doing.
These five categories represent the different modes of learning. [These are actually a combination of modes. For more on the theory, check out these links - 1, 2, 3]. They are not mutually exclusive. Some people can learn in multiple ways, but most people have one dominant mode of learning and other minor modes of learning.
Think back to your college batch, and you would find a few classmates who fit each of the above categories. The college environment is designed to present multiple methods of learning. You can either listen to the lecturer, try out excercises, attend lab sessions, talk to your classmates about a topic, or read the textbook.
Now, someone is going to point out that (in most of India at least) lecturers are often recent college graduates who couldn’t get any other job, that the textbooks are written to maximise your exam score rather than teach anything, most students take down notes verbatim without any understanding and the labs are underfunded relics. This is a topic for another day. For now, lets just assume that they support all methods of learning.
Let’s get back to the present now.
Scenario I: Your company has a training programme under which they have called someone to give a seminar on Design Patterns. You’re a Project Manager. Madhav, a member of your team, will be doing some design work soon, so you send him over to attend the seminar. The only problem is that Madhav learns by reading, not listening. Not surprisingly the seminar is extremely boring for him and he sleeps through it.
Scenario II: You are working on a new project and have just recieved a thick list of requirements. You pass the requirements to Priyanka, the lead programmer, and ask her to take a look. The problem is, Priyanka learns by talking, not by reading. The next day, the coversation goes like this:
You: So did you have a look at the requirements I passed you?
Priyanka: I had a look, but they look complicated. Can we have a meeting to discuss them?
You: I’m busy right now. I’ll be back in two days to check on your progress.
2 days later…
You: So how are the requirements? I need to give an estimate for the completion date this evening.
Priyanka: I’m not sure I understand it. Can we discuss it?
You: You still don’t understand it? I gave you two extra days. What more do you want? Meetings are just a waste of time. Can’t you just read it and give me an estimate? I need to give an estimate today.
Ouch.
Meanwhile, Scott Adams is drawing you in the next Dilbert strip.
Most managers don’t really understand the modes of learning of their team members. If Priyanka learns by talking, the manager should know it and let her talk about the requirements. Forcing her to read the requirements will go nowhere. Similarly if Ramesh likes to read, his manager should pass his some reading material before he attends the seminar. The primary responsibility of a manager is to enable his or her team members to do their work as best they can, and knowing their learning modes can help with this.
Companies also like to talk about how employee oriented they are, and about their professional development policies, but in most cases this just means that they shove their employees through a couple of seminars a year, just because they have to.
Real professional development is a lot more than just sending everyone to a few seminars. Companies need to take a hint from colleges where most of the real learning takes place. They need a good library where the readers can hang out. They need cool co-workers so that the talkers can talk with each other and learn. They need ad-hoc groups of people who learn by doing to get together and do side projects. They need to create internal blogs so that the writers can write stuff, and of course, the good old seminars for the listeners to attend.
Any comments? How is it at the companies you work (or worked) at?
This post is a part of the selected archive.
I’m going back to my college days for this the first part of this essay. What I want to discuss is the different modes of learning. This will probably come as no surprise to most of you: Different people learn through different means.
Some learn by listening. Remember people who just sat in class and absorbed the entire lecture ? They learnt by listening. Then there are those who learn by writing. They take notes. Some people learn by reading. They just sleep in all the clases, then go home, read the text book and ace the exam. Some learn by talking. They need to discuess the topic with someone else to clarify their thinking. Finally, we all know that student who could write great programs on the computer, but could barely follow what was going on in class. They learnt by doing.
These five categories represent the different modes of learning. [These are actually a combination of modes. For more on the theory, check out these links - 1, 2, 3]. They are not mutually exclusive. Some people can learn in multiple ways, but most people have one dominant mode of learning and other minor modes of learning.
Think back to your college batch, and you would find a few classmates who fit each of the above categories. The college environment is designed to present multiple methods of learning. You can either listen to the lecturer, try out excercises, attend lab sessions, talk to your classmates about a topic, or read the textbook.
Now, someone is going to point out that (in most of India at least) lecturers are often recent college graduates who couldn’t get any other job, that the textbooks are written to maximise your exam score rather than teach anything, most students take down notes verbatim without any understanding and the labs are underfunded relics. This is a topic for another day. For now, lets just assume that they support all methods of learning.
Let’s get back to the present now.
Scenario I: Your company has a training programme under which they have called someone to give a seminar on Design Patterns. You’re a Project Manager. Madhav, a member of your team, will be doing some design work soon, so you send him over to attend the seminar. The only problem is that Madhav learns by reading, not listening. Not surprisingly the seminar is extremely boring for him and he sleeps through it.
Scenario II: You are working on a new project and have just recieved a thick list of requirements. You pass the requirements to Priyanka, the lead programmer, and ask her to take a look. The problem is, Priyanka learns by talking, not by reading. The next day, the coversation goes like this:
You: So did you have a look at the requirements I passed you?
Priyanka: I had a look, but they look complicated. Can we have a meeting to discuss them?
You: I’m busy right now. I’ll be back in two days to check on your progress.
2 days later…
You: So how are the requirements? I need to give an estimate for the completion date this evening.
Priyanka: I’m not sure I understand it. Can we discuss it?
You: You still don’t understand it? I gave you two extra days. What more do you want? Meetings are just a waste of time. Can’t you just read it and give me an estimate? I need to give an estimate today.
Ouch.
Meanwhile, Scott Adams is drawing you in the next Dilbert strip.
Most managers don’t really understand the modes of learning of their team members. If Priyanka learns by talking, the manager should know it and let her talk about the requirements. Forcing her to read the requirements will go nowhere. Similarly if Ramesh likes to read, his manager should pass his some reading material before he attends the seminar. The primary responsibility of a manager is to enable his or her team members to do their work as best they can, and knowing their learning modes can help with this.
Companies also like to talk about how employee oriented they are, and about their professional development policies, but in most cases this just means that they shove their employees through a couple of seminars a year, just because they have to.
Real professional development is a lot more than just sending everyone to a few seminars. Companies need to take a hint from colleges where most of the real learning takes place. They need a good library where the readers can hang out. They need cool co-workers so that the talkers can talk with each other and learn. They need ad-hoc groups of people who learn by doing to get together and do side projects. They need to create internal blogs so that the writers can write stuff, and of course, the good old seminars for the listeners to attend.
Any comments? How is it at the companies you work (or worked) at?
This post is a part of the selected archive.
Monday, July 18, 2005
Monday, July 04, 2005
NASA - Deep Impact
Check out these pages on the NASA Deep Impact mission. The mission was to hit the comet Tempel 1 with an impactor to clear the top layer of the comet. The spacecraft then makes measurements of the chemicals which are underneatg the comet's top surface. Cool huh?
Anyway, latest news is that the impactor has successfully hit the comet Tempel 1. Check out this image of the impactor colliding with the comet. The next phase is for the Flyby spacecraft to make its closest approach to the comet. Then the press conference in a few hours time.
Anyway, latest news is that the impactor has successfully hit the comet Tempel 1. Check out this image of the impactor colliding with the comet. The next phase is for the Flyby spacecraft to make its closest approach to the comet. Then the press conference in a few hours time.
Saturday, July 02, 2005
Counting The Miles
Counting The Miles: "The point is not that customers demand it or don't demand it, because that's absolutely not the viewpoint of Honda. When you are a philosophy-driven company, you don't ask the customer if they agree with your philosophy."
Friday, July 01, 2005
TheFeature :: The End of the Road
Just read todays article that TheFeature is going to be closing after 5 years.
TheFeature was an awesome site on mobile technology. It was not an ordinary news site, but featured a number of excellently written and thought provoking articles by some very talented writers.
From the site:
For those who used to visit it, see the comments for links to the personal blogs of the various authors.
TheFeature was an awesome site on mobile technology. It was not an ordinary news site, but featured a number of excellently written and thought provoking articles by some very talented writers.
From the site:
Now is the time for us to step back, and let the conversation and community move forward on its own. It's been a great ride, and we're glad that everyone could join us. So, would the last one out please turn off the lights...
For those who used to visit it, see the comments for links to the personal blogs of the various authors.
Subscribe to:
Posts (Atom)