Let us start with the first source of technical risk, the high-risk subsystem. Which subsystems have high technical risk? To assess this we must perform our project-level analysis to determine how each program objective (expense, cost, performance, and speed) will impact profits. Then we assess each subsystem to determine how it might impact each of these factors. The easiest way to do this is to use a team meeting in which members estimate the downside risk for each subsystem in terms of magnitude and probability. This can be done by having each member assess risks independently, having a discussion on why different team members have rated risk differently, and then having team members reassess risks. The output of such a meeting is a surprisingly good understanding of project risk. Contrary to the common view that unknown risks are most important, most teams are surprisingly aware of where they are likely to fail in a program.

This reminds me so much of the Agile practice of planning poker that I’m dubbing it “risk poker”. Both practices make sense to me because they use crowdsourcing to solve the problem. I think software teams are more aware of the risks on the project than they typically give themselves credit for, leading to the paradoxical value of this practice. By doing this practice, teams make explicit the knowledge that they already have but are often hesitant to act on for one reason or another.

While doing some basic research to see if this term had been employed yet, I also stumbled across protection poker, which deals more with security risks.

Perhaps I’m reinventing the wheel and risk poker is a well-known concept with a different name. Has anyone employed something like this on a project?

Original article: A Tool For Your Toolbox: Risk Poker

On a long enough time line, the survival rate for everyone drops to zero.
— Chuck Palahniuk, Fight Club

In the long run, every signal dies. Paper rots, genes mutate, forests burn, files corrupt. Error correcting codes help, but they aren’t enough. Perfect preservation of effort is not the way of the universe. Human languages evolve and break down meaning.

Will my personal journal be lost in an accident following the poisson distribution within my lifetime? Will my grandchildren care enough to translate my life’s work to the technology of the day before it is unreadable? There is a difference between preservation and the ability to understand, as Robert Scoble points out.

Software is a signal. It stops when the cost of maintaining it exceeds the value derived. Strangely, software has a longer signal than usually envisioned.

Some signals stay stronger longer. I know more about Plato than I do about most of the people on my street. Millions of people have come before me that I will never know anything about, billions living right now that I will never hear about. Does this imply a mediocre life? People are still riveted by JFK. Elvis lives. Surely there is a high signal strength for them. Much replication, remarkable, revelatory about the human condition. But most people will not be remembered outside of their family tree.

Spawning children spreads gene and life information with some lossiness.

Linus Torvalds said “Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it.” In the long run, though, all signals are lossy.

Before a signal starts, I imagine it looks like this:

From nothing comes something, if only briefly. Most signals looks something like this:

A typical blog has a few posts, topical, uninteresting, no replication. The typical newsletter has a few editions and then fades to nothing. The signal returns to zero quickly.

Some signals, however, look more like this, and they are rather exceptional:

Over the span of the universe, though, all signals that we can comprehend look like this:

The strength and length of any signal is too small to stand out from the nothingness and noise. It’s on that line somewhere, but too short to be meaningful.

My thoughts on what to do about this:

Spread signals. Great ideas will replicate faster, great works will be preserved longer.

Start signals. The best measure of effectiveness is how long that signal lasts. Writing, music, software, companies, groups, buildings. Life is inherently a signal, something finite, an exception to entropy. One’s life might be definable by the signals started, the external manifestation of internal capacities.

Original article: Signal and Meaning

Journaling could include writing down a technique or rule of thumb used, a page of a book that was helpful in a certain area, or who to contact in a different department in case of questions in a specific area. Sometimes it could be something that went particularly well so that he can look back when times are tough and remember a time when he persevered. Other times it is something that didn’t go as well as he hoped. He also does this to clarify his own knowledge so that when he needs information he has a place to look, and for potentially transferring that knowledge to other people.

I recently tried experimenting with this technique. I suppose that I like writing, so this came somewhat naturally. I liked separating this from other writing that I do because it seems useful to have it all in one place. I am just capturing knowledge that I have gained from working on a project. Writing this down regularly is really helpful in writing documentation later because you explicitly state what you have recently learned. This prevents me from being blinded to what I learned and taking it for granted. It might be obvious to me at the end of a project why the build works the way that it does, but along the way I needed to learn a lot of things and make various decisions. So this seems to be a good way of documenting decisions for later understanding and analysis of results.

Here’s an example of something I wrote (sanitized):

20100203 - 1531

While a PDF is printing to file (which is an excellent way
to save paper), let me recount how I added a new
HelpPDFBuilder to the application.  I modified the
HelpApplication.exe.config file pursuant to the rest of the
file.  I added references in the code to the new class.
Then, I expected everything to work.  However, the changes
in the HelpApplication.exe.config file did not get picked up
by the application.  The problem was two-fold.  First, I had
commented out the post-build steps, which meant that the
config file did not get reexamined.  I uncommented these,
and it still didn't work.  The next problem was that I did
not then copy the newly touched config file to the bin
directory.  This process is clumsy, and it would be nice if
it was improved somehow.

I would say that this document should probably contain things that I would be fine with anyone reading. If I have a beef with a coworker, I should probably talk with them about it or write it somewhere more private. This just ensures that I am writing things down that are actually useful and won’t bite me in the rear some time later.

Documenting things moderately well also helps me because the next person knows more and has fewer questions. The insurance company mentioned actually has a process for transferring responsibilities on projects. Also, at the end of someone’s career there, they have a process for sitting the person down and doing a knowledge transfer exercise by having different people interview them. This seems quite interesting. It seems like a really good way to not lose information and has the side effect of validating the person’s career there and allowing them to tell stories that will live on for some time to come.

The key here seems to be writing things down that seem obvious in retrospect but are difficult to acquire. It doesn’t need to be in a complicated format (mine’s a text file) or take a long time. Maybe five or ten minutes a day of the most important things you learned would be of immense value when you or someone else comes back to a project in a year’s time.

Does anyone else use something like this? What did I miss?

Original article: How to Write a Work Journal

Experience

I’ll admit that I got a mulligan. It was a Ruby on Rails project for an internal tool. I hadn’t worked with that technology stack much before. I kind of hacked something together based on the requirements, and it worked fine. There were few tests, and the design definitely did not use best practices. But it worked.

Next, I worked on a six-month-long Rails project using mostly TDD. After that, an opportunity arose to clean up the internal tool and add some features.

It felt really good. I felt like I knew the environment so much better, and could see where problems in the code could be easily solved using better Rails or Ruby techniques. It was quite exciting. At times, I was surprised that the code actually worked at all. I think that most developers rarely get this type of opportunity unless they are on a maintenance project, and I do think it was a valuable experience to see the aftermath of my own coding.

Synthesis

But afterwards I came to the realization that developers shouldn’t feel guilty about producing software. There are always going to be new technologies and practices to learn, tradeoffs to be made, and hindsight clearer than the present view. Should I refactor this class now or later? Should I make this easily extensible, or are we truly not going to need it? What should we work on first to reduce the technical risk on this project?

After every book I read on a subject, I learn new techniques and ways of thinking about problems. But this shouldn’t stop activity in the present. I will never have one hundred percent of the knowledge I need, and the solutions that I come up will only satisfice the problem.

I’m assuming that developers are really putting their best effort forth. This doesn’t absolve the developer from learning from their mistakes or preemptively learning.

I’m just trying to say that developers shouldn’t feel bad because they didn’t know enough to prevent every problem or solve every dilemma in the best way possible. Seeing mistakes in the past for what they are just indicates growth. Getting it right every time implies skill stagnation or perfection. Which one is more likely?

Have you had an experience where you wish you could go back and change something on a software project? A time when you read your own code and cringed? Where’s the balance between getting things right and getting things done? Consider leaving a comment!

Original article: Guilty Developer Syndrome

Pecha Kucha

Pecha Kucha is a challenging presentation format where presenters have twenty slides shown for twenty seconds each. Presenters are forced to practice and consider what they will say and how they will transition between sections, and are promptly jerked off of the stage after their time is up.

Complaining

If you can change your situation, change it. If you can stop yourself from complaining, don’t complain. Always consider these first and consider your underlying assumptions again. What seems out of your control is often in your control but outside of what you let yourself believe. Considering complaining about your relationship or your job or your house? What larger problems are under the surface, and what can you do about them? Even if you don’t believe you can change your situation, you can likely change your attitude about it.

Preparation

Here are the steps to correctly prepare for your complaint:

1. Reflect on the problem and ensure there is little you can do to improve it.
2. Estimate how long it will take you to complain appropriately.
3. Pick a peer group that knows you.
4. Pick a spot where the conversation has lulled.
5. Ensure that complaining to this group at this time will actually help you feel better.

Constructive?

The last bullet above is key because the purpose is to release stress due to not being able to change something. If you won’t feel better after doing this, then you should not do it. Your audience is much more willing to listen patiently if they know it will likely help you.

There has been a lot written about how to complain or criticize constructively. However, being constructive in a logical sense is not the goal of this method. Rather, the presentation implies that you have not found a satisfactory solution, but still feel emotionally attached to the problem.

You can present this as, “Guys, I have something to complain about that does not affect you and that I don’t have a solution for, and I would feel a lot better if I could vent about it. Can I talk about this for forty-five seconds or less, and then we don’t have to talk about it any more?”

Timebox

Hence, the key difference is that Pecha Kucha complaining has a well-defined time limit.

This contract forces your complaint to be articulate and limits your audience’s commitment. No stray word or obscenity will likely help you convey your dissatisfaction within the limits you have set in advance. Rather than spacing out during the complaint or being annoyed or just wondering how long you are going to be complaining, your group listens closely because they know exactly how long this will take. It’s also more compelling than standard complaining because you have obviously considered the weight of your complaint, the value it has to you, and how much time it will take. The less you use this method or any other form of complaining, the more weight it will have. The better your complaints, the more willing people might be to hear them.

Stating at the outset that the complaint does not affect them is important to reducing defensiveness. Obviously you should not say that you are not going to complain about someone and then proceed to complain about them. It also probably helps if you don’t complain about people, or if you do, it is someone that the audience does not know. This prevents you or them from worrying about the actual people involved.

Execution

A good structured complaint should cover:

1. the problem with context
2. your response and emotions
3. possible or considered resolutions
4. thanking everyone for listening

If you are successful in estimating how much time you have and structuring your thoughts, this all should come out as a coherent whole. You may get some followup feedback, but don’t press for it. Since your audience knows that you are not looking for solutions, they are unlikely to offer them, and, if you presented your complaint well, will instead give honest feedback of your situation and help validate your emotions. Again, this technique can be overdone, so use it and other forms of complaining sparingly. Always seek to solve your own problems and emotional hangups internally before asking others for help.

Your thoughts

Have you ever used a structure like this? Have you seen me use it, and what were your thoughts (both the idea and my implementation?) How does this relate to Men Are From Mars, Women Are From Venus or other conceptual communication frameworks? Is this an improvement over standard water cooler complaining, or am I deluding myself? Leave a comment!

Original article: Pecha Kucha Complaining

// TODO: implement the foo module here
...
// HACK here be dragons
...
// XXX
...
/* FIXME:  late at night, I need some sleep */
...

One advantage of using these tags is that they are easy to search for and give an understanding of where the code can be improved. Most IDEs even have a special view to look for these kinds of things.

My personal view is that writing a comment like these basically says that I should do something. If it gets checked into source control then it’s a problem. I should either address this right now or create a task to address the problem in the future. In the rare case that something is urgently broken, it’s best to fix it and then immediately figure out the root cause and any ramifications, when the problem is freshest. Delaying just adds a time cost to whoever tries to fix this in the future. Maintainers need to ask, “Is this still relevant or important, and how do I fix it if it is?” The second option is to put TODOs into a standard tracking system for later analysis instead. What seems urgent to fix at this time might not matter much in the greater scheme of things, so this work should be prioritized like everything else.

TODOs are definitely not acceptable for commenting out large swaths of code that break the build. The build exists for a reason–use it as a tool for creating higher quality integrated code. If your code doesn’t integrate, it’s your problem to fix it immediately. Commented-out tests are worse than useless because they add to the codebase and are not kept in sync with the main development line.

As a tangent, I usually write a date and author in comments. Even though people can use repository annotations (svn/git blame/praise), it’s much easier to see how relevant this comment is.

// AJP20021116 - I'm not sure that this works for all values of N.

Hence, if you were working on a project and saw this comment, it’s clear that it immediately is probably out of date or just not that important if it hasn’t been fixed in the past eight years. If I’m still around, future developers can ask me to recall what I was thinking.

What are your thoughts? Do you use TODOs in your code? What do you use them for? Do they make maintaining a project easier or harder?

Original article: TODO: FIXME, HACK, and XXX

• where I found something
• how I found it
• who recommended it
• how long ago the information was published
• the context of techniques
• how surprising the information was to me

I contend that this meta-information is actually more valuable than the information itself.

It’s helpful to think about these attributes to get higher signal streams of information. When I find that a particular blog or person has interesting content, I listen much more closely to what they have to say. While I don’t turn critical thinking off, I don’t need to spend as much time considering the source. Links and ideas presented from a trustworthy source tend to be of higher quality. Finding a good source of information makes it much easier to get good information in the future.

Conversely, remembering meta-information allows me to debug and debunk things that I have come in contact with. When I start to disagree with someone whose opinion I previously agreed with, I also think critically about other things that they said or thought. Perhaps there are other views that they held that are also incorrect, and I’m basing my thoughts on this incorrect information. This helps me realize when my mental models need to shift. Everyone has a bias, and I want to make sure that I understand their bias and that is it not harmful to me. If I realize that a much-read software pundit just started selling bug-tracking software, I might start to examine the quality of his articles because of a potential conflict of interest. Similarly, if I understand that the last time I read about something was five years ago and believe my information be out of date, I might preemptively decide to brush up.

Filtering out theories based on recommender is clearly not using the scientific method, but it’s an effective way to get more interesting, useful, and accurate information in a time-efficient manner. Social media proponents purport that search is dead, or at least the type of search commonly thought of today. Tomorrow’s search will be more personalized. I think that this makes sense–crowdsourcing humans are better than computers at the present for separating remarkable things from the merely great and good, and facilitate the spread of useful memes.

Software developers and managers often subscribe to the belief of best practices. After reading Managing the Design Factory by Don Reinertsen, I don’t think best practices exist. To say that something is a best practice and can be applied blindly to any situation ignores the context. Perhaps I’m using a straw man here. But no practice used in the wrong context can be responsibly effective. While I might read that a particular practice was useful for someone, I cannot be considered a responsible practitioner unless I understand their rationale and the constraints of their project and think that the practice will apply to my situation. For example, if I am following various entrepreneurial types and remember a technique for increasing sales, it is crucial to be able to remember who gave the advice because of the differences between bootstrapped and VC-backed startups. Trying to apply advice from one category to the other will likely have deleterious, if not disastrous, effects. At best, the outcome will be positive even though the understanding was flawed–a lucky break. So meta-information is crucial in making effective decisions based on information.

Asking “Why do I think X?” and being able to figure out the answer is invaluable. The answer is possible with meta-information. Thinking about meta-information forms a structure for information to go into for future review and comparison. Forming this structure allows one to navigate through information overload by being able to quickly gather up-to-date information and ensure that this information is reasonably correct. Do they teach this in school? How does one learn this technique?

It’s interesting to talk with people who can trace their mental models. I typically place a higher degree of trust in someone who knows not only what they think, but why they think it, with relevant citations. I can trace their thoughts and compare them to my own structures. Doing this well requires a focus on the context and validity of information.

Writing this post leads me to consider that the best information sources will actively supply context to reduce the overhead for readers. Useful case studies or research papers supply the problem, the specific conditions of the situation, and the attempted solution with metrics to show the effectiveness. The best journalism paints a broad picture and gives not only information, but context. These are the articles that people reference and point others to, because they are timeless. Every forgettable blog or forum post contains mostly the author’s unverifiable and subjective experiences and musings.

The last thought process that I want to discuss I got primarily from Managing the Design Factory: information is valuable for disproving theories. When I come across something that surprises me, I get pretty excited. The surprise could be a new way of linking disparate concepts or just a fact that does not mesh with my worldview. New perspectives could very well be incorrect, but it more likely that the context is different from my normal context, or the approach is different from my normal approach. The reason surprising information excites me is because it means that I am not wasting my time. Information is most valuable when it doesn’t fit cleanly into my current mental models. This is more along the lines of the scientific method. If I only look for confirmation of my own theories, I will never disprove them and will instead become infatuated with them. However, if I actively introspect and search for information that might disprove my own models, I stand to be more correct in the long run.

Original article: How to Use Meta-information Effectively

Had an idea for a for-fun app that regularly informs users of time-based facts. The problem that the app solves is the inability of the mind to consistently simulate the age of things. The app would take salient world events, people’s ages and significant personal events (you bought your couch 4 years ago) and periodically remind users of how long it’s been since those events occurred. This would allow users to continually shape their awareness of and reflect on the passage of time. It is an established phenomenon that time appears to speed up as one ages so this app could be helpful for dealing with this. Users could even state how surprised they were by certain facts to quantify the normally subjective passage of time.

This tool could be used for goal alignment and future-orientation awareness. “When you were twenty-five you said you wanted to be a pro surfer by thirty. How’s that coming along?” Or perhaps: “Remember when you thought that 2020 was a long way away? Well, it’s only ten years away now.”

Original article: Why My Parents Don’t Know How Old I Am

But then I thought to myself that there was one page that I looked at recently that was actually pretty good. It was a page detailing the Meyers-Briggs type ENTP, which I think most closely resembles my personality type. So I searched for it and pulled the remains from Google cache, and decided to repost it. I corrected some spelling and wording choices, added punctuation, and formatted a bit differently.

The first portion is especially good. No other descriptions on the internet got me nodding my head and laughing in agreement quite as much as this one did. While I don’t think that this personality type defines me, it is a useful model to help understand what natural biases and unaware blind spots that I might have, as well as what my natural strengths and talents are. I would recommend doing this if you haven’t already.

Enjoy!

ENTP – The Innovator

Profile by Sandra Krebs Hirsch and Jean Kummerow

ENTPs are known for their quest of the novel and complex. They have faith in their ability to improvise and to overcome any challenges that they face. They are highly independent, and value adaptability and innovation. They may be several steps ahead of others in encouraging and valuing change. They hate uninspired routine and resist hierarchical and bureaucratic structures that are not functional. They need freedom for action.

Living

ENTPs are lively children who question established truths and norms, dream and scheme, and develop unusual ways of doing traditional childhood things. The ENTP child is oriented toward doing the unique, which may mean taking risks and outwitting parental, school, and societal authority. They enjoy creating projects and following interests that are unusual and different.

ENTP children enjoy inventing new toys, dances, and languages. Because they are outgoing in their personality style, they often engage other children in their projects and assign them particular roles to play. ENTPs rarely accept things just as they are. They like to test or explore to see new meanings and relationships. When things do not go as they want, they use their ingenuity and cleverness to bring people and situations around to their point of view.

As young adults, when ENTPs choose a career for themselves, they tend to set flexible goals that allow them to incorporate new information and accommodate to new circumstances when they come along. It is hard for ENTPs not to be able to explore the road not taken. Their byword is “keep your options open.” Sometimes this flexibility can look like indecision to outsiders.

As adults, ENTPs take advantage of opportunities. Because of their ability to see relationships and connections between seemingly unrelated things, they are able to realize the potential in many things. When they see and opportunity that others have missed, they set action-oriented strategies that allow them the greatest flexibility to achieve the results they want. The worst job for them is working for someone who demands considerable rule following or tries too often to tell or order, rather than make suggestions to the ENTP. Throughout their careers, ENTPs want their work to be enjoyable, with interesting possibilities for applications. Additionally, having their work widely acclaimed and accepted as a unique contribution would be highly gratifying for ENTPs. They also weave in vacations whenever possible and want a flexible work schedule.

Learning and Working

ENTPs are relentless learners. When the subject matter interests them, they are able to find meaning in whatever they are studying. Knowledge is important to them, but they may not feel the need to show this to their teachers and therefore may be somewhat lackadaisical about assignments and tests.

ENTPs use their enthusiasm and energy to get others involved in their learning. They learn through give-and-take discussions and by questioning and challenging others. They are quick, verbal, and logical, preferring to use their skills in interactions with others. ENTPs look at the logical foundations in others’ thinking and build on them to develop their own conceptual systems. They want to be taught concepts rather then facts. Models are important to them. They typically absorb their teacher’s material and present it in a framework that ties all of the elements together.

They like to challenge their teachers and classmates and enjoy competitive learning tasks through which they can show their conceptual versatility. They may also enjoy independent study in which they can pursue and area of interest.

ENTPs contribute an innovative, versatile, and enterprising approach to work. They view limitations as challenges to be overcome and look for new ways to do things. They need to find a niche for themselves in order to be free to maneuver. They prefer the start-up phase of a project rather than the follow-through or maintenance phase. Once the project is designed, they prefer to turn it over to someone else. They take initiative and inspire others toward greater accomplishments and challenges.

ENTPs usually find work that involves an analytical, entrepreneurial, and creative focus. They tend to tolerate ambiguity well. They want to be in situations in which they can take intellectual risks and meet challenges. To perform in their best fashion, they prefer flexibility and versatility. While they like status and titles, they ultimately want to be judged on their innovative accomplishments. They take advantage of changing circumstances and work those circumstances into their plans. As a result, they function effectively in chaotic times.

Some occupations seem to be more appealing to ENTPs: actor, chemical engineer, computer analyst, credit investigator, journalist, marketeer, photographer, psychiatrist, public relations worker, sales agent, and other occupations that allow them to be innovative.

Loving

For the ENTP, falling in love occurs when they feel that there is a good fit with the other person. Often within the first meeting, ENTPs will know whether the relationship has any real potential. ENTPs may find it difficult to commit to anyone until the right person comes along. During this period, ENTPs explore the closeness until they can be certain that they have looked at all of the possibilities. Because of this, they are not likely to settle down early. When they do become involved in a relationship, they generally want to maintain as much independence and freedom as their loved one can tolerate. Their mates may need to have high self-esteem and to be independent themselves in order to accept the ENTP need for freedom and novelty.

For ENTPs, falling out of love, which may not always occur, results when their vision of the relationship does not square with reality. Sometimes they will select someone who offers stability and comfort and ENTPs later will become bored with the stability. When scorned, ENTPs use their powerful and broad-reaching analysis to explain the reasons why the relationship was not good in the first place. Additionally, they may become competitive with their former partner and work hard to win. ENTPs do not like to lose at anything they undertake.

Profile by David Keirsey

ENTPs wish to exercise their ingenuity in the world of people and things. Found in about five out of every hundred people, ENTP’s extrovert intuition; thus they deal imaginatively with social relationships as well as physical and mechanical relations. They are very alert to what is apt to occur next, and always sensitive to possibilities.

ENTPs are good at analysis, especially functional analysis, and have both a tolerance for and enjoyment of the complex. Usually enthusiastic, ENTPs are apt to express interest in everything, and thus are a source of inspiration to others, who find themselves caught up by the ENTP’s enthusiasm. This type is delighted over many things and so is easy to please, often showing the effervescence of their NF counterpart, the ENFP. The ENTP is the most reluctant of all the types to do things in a particular manner just because that is the way things always have been done. They characteristically have an eye out for a better way, always on the lookout for new projects, new activities, new procedures.

ENTPs are confident in the value of their pursuits and display a charming capacity to ignore the standard, the traditional, and the authoritative. As a result of this open attitude, they often bring a fresh, new approach to their work and their lives. The ENTP is a keen judge of the pragmatics of both the social and the mechanical, and may become expert at directing relationships between means and ends.

Where the introverted NTP sees design as an end in itself, the extroverted NTP sees design as a means: the end is the invention that works, the prototype that is replicable. Ideas are valuable when and only when they make possible actions and objects. “It can’t be done” is a challenge to an ENTP and elicits a reaction of “I can do it.” They are not, however, the movers of mountains as are the INTJs. Rather, the faith of the ENTPs is in their ability to improvise something, and they display an unusual talent for rising to the expediency of a situation. Superficially, ENTPs resemble ESTPs in their derring-do. But the focus of the ENTP is on the competency and the sense of power this gives, rather than on the feeling of freedom of action experienced by the ESTP.

ENTPs can be fascinating conversationalists, able as they are to follow the complex verbalizations of others. They may deliberately employ debate tactics to the disadvantage of their opponents, even when the “opponents” are close associates and valued friends. ENTPs are the most able of all types to maintain a one-up position with others. They value adaptability and innovation and thus respond quickly and adeptly to another’s shifting position. They may even be several jumps ahead. The ENTP, talkative and motivating, is often the life of an enterprise. The ENTP can be an entrepreneur and cleverly makes do with whatever or whoever is at hand, counting on ingenuity to solve problems as they arise, rather than carefully generating a detailed blueprint in advance. A rough draft is all that an ENTP needs to feel confident and ready to proceed into action, counting on the ability to improvise as a situation develops. Because of this tendency to depend on ingenuity and improvision, they may neglect very necessary preparation at times. After repeated failures in situations where improvising has met with defeat, the ENTP may develop ways of avoiding such situations as a substitute to thorough preparation.

Career

ENTPs can succeed in a variety of occupations, as long as the job does not involve too much humdrum routine. At this point, they become restless. If a project in which they are engaged is no longer challenging, they tend to lose interest in that project and fail to follow through–often to the discomfort of colleagues.

Seldom are ENTPs conformists. ENTPs enjoy outwitting the system and use rules and regulations within the system to win the game–whatever it may be. They understand well the politics of institutions and deal with these realities very well, always aiming to understand the people within the system rather than to judge them. ENTPs are good at innovative projects and can administer them well if dull routine is not involved. They usually are outstanding teachers, continuously devising new participative ways to make learning exciting for the students. As an employee, an ENTP may work against the system just for the joy of being one-up. For ENTPs, to be taken in, to be manipulated by another, is humiliating; this offends their joy in being masters of the art of one-upmanship. ENTPs are the natural engineers of human relationships and human systems. Their good humor and optimistic outlook tend to be contagious, and people seek out their company.

Home

As mates, ENTPs tend to create a lively living environment. They are gregarious, laugh easily and often, and are typically in good humor. Orderliness in the routines of daily living is not apt to inspire them; they usually solve this problem by mobilizing those around them. Tom Sawyer illustrated this talent when he solved the problem of getting Aunt Polly’s fence whitewashed. Life with ENTPs is likely to be a daring adventure; they can lead families to physical and economic dangers. ENTPs improvise to remain unaware that they do not have the necessary knowledge of the situation to ward off such dangers.

If the mate of an ENTP is not competitive, he or she is likely to find the one-up/one-down transactions somewhat wearing. If the mate is competitive, the result might be conflict. Although usually good providers of economic necessities, ENTPs at times engage in brinkmanship with their careers, placing them in jeopardy and behaving as if unaware of the consequences; they may thus offer unnecessary challenges to those who have power over their professional success. When challenges elicit negative responses from superiors, ENTPs are apt to react with delight at having an opportunity to improvise a solution to the crisis and, more often than not, they succeed in doing so.

ENTPs are likely to have all sorts of hobbies and to be experts in unexpected areas, but they are not apt to share these hobbies with their mates or children in the sense of teaching them. In fact, ENTPs may be very inconsistent in the attention given to offspring. Usually, it is feast or famine. ENTPs have a lively circle of friends and are interested in their ideas and activities. They are usually easy-going, seldom critical or nagging. At their worst, they can show undependable, fickle characteristics and may be rather easily discouraged.

Midlife

At midlife ENTPs can allow their tendency to experiment recklessly to get out of hand and may destroy or discard the work of half a lifetime, both in personal relationships and in careers. Energy spent in sorting out priorities and values may be a good investment at this time. Developing an increased awareness of emotional reactions and expanding the intensity and range of these through self-development work may be something ENTPs might want to consider at midlife. An increased repertoire of introverted-type activities; for example, gardening, painting, or reading may be a source of pleasure to ENTPs.

Mates

The inventive ENTP finds in the ISFJ a neat complementary for his enterprise, for in the ISFJ he finds the supreme conservator. The conservator, broadly conceived, is morally bound to ensure the material and legal welfare of his or her charge. The inventor, also broadly conceived, is bent on replacing whatever tools, operation, or enterprise now exists with a better one. Out to exercise his ingenuity in bettering things, the ENTP is of necessity iconoclastic and tends to be so seen. So he can get into a bit of trouble with the elders, who usually are not all that pleased to see their tried-and-true tools, operations, and enterprises blithely set aside for the ENTPs better mousetrap. The ISFJ, mated to this inventive rascal, takes on the task of squaring things with the establishment.

The ENTP also may be attracted to his opposite on the N side: he approaches the INFJ. But the INFJ is humorously and preposterously different from the seemingly similar ISFJ. In the INFJ lies the soul of the “author”-the meaning-giver, the mystic, the oracle. Perhaps the INFJ is a conservator of the soul, a sort of messiah. At any rate, there is something about the “author” (very broadly conceived) which the ENTP covets. Prometheus had to pay dearly for giving fire to man. The Promethean ENTP may figure that, though his INFJ mate may not rescue his body from the vultures, at least the INFJ might rescue his soul from Hell.

Anyway…

Well, that got a bit speculative at the end, but perhaps you saw some tendencies that I have in there. I think the closest things for me are the “being interested in learning everything” thread and not wanting to get stuck in a situation that is not challenging. The thing that I probably least see is the one-upmanship, although perhaps I don’t even realize how much I do this. I haven’t asked any “mates” for a personality breakdown, so I’m not sure how accurate the love sections are. But as I stated earlier, a useful tool, nonetheless.

Any other thoughts? Maybe I’m way off base, and am actually not this type… It would be really interesting to see what other people had as their types. I often have a hard time ascertaining what types people are. Leave a comment!

Original article: Meyers-Briggs – ENTP

But please, use your own blog or website to experiment.

Select a load-testing tool

I wanted to survive a fairly heavy load, so I was looking for around three responses per second from the server (which amounts to about 10k requests served per hour.) Anything more and I guess I’ll have to turn people away.

I looked at some load-testing tools that were available for Ubuntu (my home machine), and siege seemed to be the easiest to install and use. Installing was as simple as:

sudo apt-get install siege

Siege comes with a man page and some basic examples. There are a lot of neat options, but I didn’t want to spend too much time on load-testing. One of the best things about this tool is that it tells you that it’s “preparing users for battle” and laying siege to the server, which is just fun.

Initial trials

I started experimenting by hitting the home page with fifteen concurrent users, but this caused a bunch of problems. This means that fifteen people are trying to hit the same page, and whenever they get a response (whether success or failure) they try to get the same page again. I then opted for starting at the minimum and scaling upward.

> siege http://22ideastreet.com -c 1
Transactions:		        1668 hits
Availability:		       98.52 %
Elapsed time:		     1973.58 secs
Data transferred:	       31.79 MB
Response time:		        0.51 secs
Transaction rate:	        0.85 trans/sec
Throughput:		        0.02 MB/sec
Concurrency:		        0.43
Successful transactions:        1692
Failed transactions:	          25
Longest transaction:	        6.86
Shortest transaction:	        0.19

I let this one run for awhile because I thought it would eventually time out and I didn’t want to lose the statistics. But it turns out that whenever you terminate the program with Ctrl+C, the statistics are automatically displayed. What this snippet doesn’t show is that hitting the specified URL will cause two redirects, one to http://22ideastreet.com/ and then one to http://22ideastreet.com/blog/. This ate up quite a bit of time. So my next experiment was to hit the blog index page directly and see how that affected the response times. Also, I upped the concurrent users a bit.

> siege http://22ideastreet.com/blog/ -c 2
Transactions:                    113 hits
Availability:                 100.00 %
Elapsed time:                  83.34 secs
Data transferred:               6.38 MB
Response time:                  0.95 secs
Transaction rate:               1.36 trans/sec
Throughput:                     0.08 MB/sec
Concurrency:                    1.28
Successful transactions:         113
Failed transactions:               0
Longest transaction:            1.72
Shortest transaction:           0.82

Still seems alright, so I added another user.

> siege http://22ideastreet.com/blog/ -c 3
Transactions:		         205 hits
Availability:		       98.56 %
Elapsed time:		      123.74 secs
Data transferred:	       11.57 MB
Response time:		        1.16 secs
Transaction rate:	        1.66 trans/sec
Throughput:		        0.09 MB/sec
Concurrency:		        1.93
Successful transactions:         205
Failed transactions:	           3
Longest transaction:	        6.26
Shortest transaction:	        0.82

Realism

Now I see the first inklings of failure at around three users at a time. I was also hitting the blog from different pages in a browser, and the responses seemed reasonable. At the time, my index page was the last three posts in their entirety, which was pretty big. So I next decided to see what the transaction rate was for an individual post. I figured that this would most closely resemble what happens when someone links to a post.

> siege http://22ideastreet.com/blog/2009/10/01/interesting-links-nascent-thoughts/ -c 5
Transactions:		         320 hits
Availability:		      100.00 %
Elapsed time:		       95.16 secs
Data transferred:	       13.83 MB
Response time:		        0.95 secs
Transaction rate:	        3.36 trans/sec   *** this gives me a warm fuzzy feeling
Throughput:		        0.15 MB/sec
Concurrency:		        3.19
Successful transactions:         320
Failed transactions:	           0
Longest transaction:	        3.09
Shortest transaction:	        0.76

Conclusions

I was pretty excited to see that I could handle about over three transactions per second without any drops, which was my initial goal.

For some reason, the WordPress stats plugin still causes my server to come to a standstill for about thirty seconds, so I think I will rely on Google Analytics in the future for seeing how many people are visiting. It’s not real-time, but gets the job done for analyzing visitor patterns and seeing what else people might be interested in based on their search queries.

Have you tried load testing your apps or blogs? What were the results? What were your favorite tools? You should post in the comments section!

Original article: My Blog Is Under Siege