Need to start writing!

Question

I think I have good content mapped out for each essay (in bullet points). I think I even have some of it paraphrased. But how do I start writing?! I work full time and every day when I come back from work I'm tired and in no mood to look at a computer screen let alone write

Even if I open up the essays, I end up just staring at the screen. How do you guys get started? I don't think I need any "motivation" or push. I need techniques to start converting bullet points into sentences... coming up with good starts for each essay (paragraph).

gregarious · Answer

I had the same problem getting started writing after brainstorming and outlining. What worked for me was ignoring the urge to craft perfect sentences and just getting something down. Even as I wrote my first draft I could tell the it wasn't too coherent but then at least the editing process can begin. For motivation, I recommend reading some applicant blogs or threads here that discuss the journey to b-school. I found it motivating to see examples of how people put so much work into their app and then had it pay off.

Sleepy · Answer

Whatever you write the first time will suck. Nothing against you, I'm sure you're a good writer with good content and a smart person, but that's what happens. Just sit down and write it out. It's a lot of work, but you can spread it out over days/weeks/months, as long as you start writing.

terp26 · Answer

those deadlines come quicker than you think. Wake up early on saturday, go to a coffee shop and start writing out your bullet points.

rhyme · Answer

Here's how I'd approach it.

Take a question, write out your bullet points. Compare your bullet point word count to the essay word limit - if you are anywhere near it, odds are, you are going to need to condense your story quite a bit. Take the bullets and get your story to (in bullet point form) to well under half the word limit, ideally more like 25%. Once you've figured that out - then start writing. Odds are, you'll still blow clear through the word limit, but its an easier way to start (in my view) than just bringing pen to paper from zero.

Two of the more common mistakes I see people make, particularly in early versions of essays

* Spend far too much of the essay of 'backfill' -- explaining the elements that lead up to X or Y (where X or Y is really the point of the story). 400 words explaining why the C++ confrabulator module in the GLEE Accounting system was broken is boring and not meaningful. To give a different example, its very interesting that your grandfather played cricket and you love it too, but if the point of the story is that you are coaching a cricket team somewhere, the point about your grandfather should be a sentence or two, maybe three, not a long drawn out trip down nostalgia lane. The "set up" for your story should be brief and to the point.

* Using too much jargon, particularly engineer and IT candidates. No one cares that you moved from java to .NET, nor do most people have a clue what that means anyway. Nor does anyone care that you convinced the dev team to go from .NET 1.1 to .NET 2.0. Etc.

* Similarly, avoid using internal acroynms, even if you define them. Two reasons. First, it makes for choppy reading ("I worked on the LAFRJD 2.0 project from ..."). Second, odds are, even if you know what it means, and even if you define it, its still rather meaningless to the person on the other end.

* Not understanding that there's a difference between what achievements you might care about and what achievements other people might care about. If a story just doesn't seem to work well on paper - or if other people can't seem to get the point of your story, consider the possibility that it's not the best story to tell, even if its something important to you.

Gotta jet.

pleonasm · Answer

Tremendously valuable tips for folks in the software industry. Actually many people in the business world will not even know what programming languages are in vogue. May be someone at MIT will but not everywhere. So if you use terms such as 'Hibernate", "J2EE" .. it may not fly well. This is the hardest part of writing essays for software engineers, because quite frankly, for must of us, J2EE is our world.

rhyme · Answer

And that brings up a second point about IT - its difficult to convey the meaning of a technical project or task in non-technical terms.

For instance, lets say you were some UNIX build manager responsible for whatever it is build managers do, which, although I've never met one, I would guess involves gathering substantial code, having it pass through some automated tests, and then attempting to create a stable testing build that can be pushed to some test environment. Lets say that in the course of your job, you designed some way to make these builds faster, or more accurate or in some way shape or form improved them. Odds are that involved some kind of modified unit testing or something like that. That kind of stuff might make sense to an IT, but it might not to non-IT. Even if it *does* make sense, it may not be clear what impact you had.

A "traditional" attempt at conveying your leadership skills might go something like this: "Having identified a bottleneck in our build process, I approached the testing lead and suggested we change the unit test procedures for the program. After carefully documenting her concerns, I was able to demonstrate that not only would my suggestion improve our build times but also reduce application error."

What I'd suggest is that you attempt to dis-aggregate the technical from the project and focus on the downstream or upstream impacts -- ideally as far removed from the technical organization as possible, and value your work in business terms.

For example, lets say the above project had to do with an online loan application system that processes a number of loans per day. You are working on rolling out a new version of the software that will add the ability to get some new kind of loan, lets say a car loan.
Starting at the very bottom of the pyramid, what have you done by improving build quality and time? Work your way up the pyramid of stakeholders until you get to something tangible and meaningful. The idea is to find the one or two key "big picture" things that you've achieved.

So for example in the above example:

You've probably reduced late night hours for your co-workers managing the builds.
From there, the next most immediate impact is that you've probably reduced cycle time for testers. 
Taking it a step further, you've probably simplified the life of some developers and perhaps made modules easier to unit test.
You've probably reduced some amount of rework and project delays.
You may have, within reason, saved the firm some money on bug fixes down the line.

In combination what do these things all essentially lead to? Improved product quality and faster product delivery. In a technical world you've had measured this through some kind of metric such as "Level 1 bugs" or "Project timeline". So you *could* say something like "my recommendations reduced overall project bugs by 20%". That's acceptable certainly, but not especially strong.

Now, take that same concept and translate it to business: In practice, from a business standpoint, what does it mean to have improved quality and faster delivery? It means your car loan application probably got to market a bit faster, and it got there with less issues than it would have otherwise.

What metric would the business use to measure those outcomes? Any number are possible - perhaps market penetration, or product growth, or sales, or perhaps customer satisfaction metric or perhaps, even just the number of car loans completed in the first year. Now, you can't go and claim that your job as a build admin resulted in an increase of $200M in annual sales - thats a bit of a stretch, but what you might be able to say is something about those sales. For instance, you might say:

"these improvements helped bring our product to market three months ahead of schedule, achieving 10% market penetration in twelve months."

or

"As a result of our hard work, including my efforts to reduce the overall project timeline, we were the first to market with an online car loan application and captured nearly $200 million in 2007 sales alone."

or

"...... which helped us develop a quality software package evidenced by our JD Powers and Associates Gold Badge of Awesomeness."

Keep it reasonable of course, recognize that your contribution is one of many (be honest) but frame the benefit in terms that are more easily understood by the average person.

Baby crying so I have to go, but hopefully that makes some sense. Also ,take my thoughts with a grain of salt, just my opinions.

gregarious · Answer

Rhyme, great tips about jargon and acronym usage! It seems that not only are those useful things to keep in mind during essay writing, but that they definitely apply to the resume and interview as well. I had numerous people tell me that on too much jargon on a resume for app purposes will stick out in a bad way. I would imagine that also holds true in an interview where there probably isn't too much extra time to be explaining everything in layman's terms.

rhyme · Answer

I see that you are in Hawaii. Everyone will just want to talk about that in interviews anyway cause that's super cool.

Irishfan · Answer

That, or paperweights.

Some people will want to talk about nothing else.

pleonasm · Answer

I wholeheartedly agree with you on the 'business aspect' of the day to day software engineer job. The hardest part of the SE job is to get a window into these aspects. To quote a real world example in my case - when I was leading the efforts for a billing software product - I had no clue about the business side of the software I was helping the team develop. Business aspects such as the ROI, cost savings etc. However if you were to ask me - why did I choose technology x over technology y - I could talk to you about it all day and if you were to be a fellow technical guys, would probably argue about it all day.

It's not that I was not interested in knowing the business side or understanding how the technical work translates up in the food chain, it's just that there was no time. In fact, we were so short on time, all the time, that even technical decisions were taken hastily leading to lot of rework. \

These tips are very valuable, if every engineer incorporated these points into the essays, they can be far more competitive in the b-school application scenario.

Is there any way this post can be made a sticky and the title changed to something like ' Essay tips for software engineers' ???

atwater · Answer

Man I hear you. I've been staring at the screen for a whole week!

rhyme · Answer

Ha-ha, ok I'll call you and talk about something else next time.

gregarious · Answer

Rhyme, yeah people are usually pretty interested in what it's like to live in Hawaii. There's definitely some pretty cool things about it, but some downsides too like traffic and the lack of seasons. It would be a good starter for on campus interviews, but probably wouldn't be as unique for a local alumni session

But anyways, back to the people who are trying to get started writing . . . I had a random idea. If you find yourself starting at the computer, why not try a dictation program so you can just talk to get your thoughts into sentences. I've never used such software before but it seems like an interesting way to fight writer's block.

gmatbschool · Answer

Update: some progress.

i decided to start writing my essays by skipping the opening paras. Maybe this is the wrong way or even a completely foolish thing to do... but it has helped. once i got over the hump of thinking about "how do i start", it became a little easier!

also i've been making notes for my recommenders and that's helping me as well.

Need to start writing!

Prep Toolkit

Top 5 GMAT Debrief Videos

615 to 715 in 15 Days (Ria's Strategies)

More than Quant/Verbal Abilities: Speed vs. Accuracy

745 with Only Self-Prep and GMAT Club

From 555 to 765: 210-point Improvement

Perfect 805 Score Debrief by Julia

My Rewards