Eight Hours to Start Ubuntu

So after trying a lot of different things - including unnecessarily changing the boot mode from "UEFI and Legacy" to just "Legacy" (in my bios) - I now have Ubuntu booting up on my new computer.  Not yet installed, mind you - more than 24 hours later and I still couldn't boot from the version of Ubuntu installed on my hard-drive.


If you:

1. Considering installing Ubuntu or have already started
2. Have a new machine with a high-end graphics card
3. Haven't used Linux for anything more than a two day pet project or only in school

Get comfortable - because it could be days before you have things working/installed.  The most important recommendation I can offer is - make sure you have a second computer (more than just a smart phone) next to you - to help walk you through all the various commands/codes you're going to need to use.

I'm Not Alone

For hours all I would get was either the screen to freeze after selecting "try Ubuntu without installing" or at one point I was able to hear the drum sound - but the screen was black with a little blinking cursor was up in the top left hand corner of the screen.  From a number of posts it sounded as if the likely culprit is my new and high-end graphics card NVIDIA GeForce GTX 780 - 3 GB - 941 GHZ (or possibly the partitioning/format of my harddrives):

http://ubuntuforums.org/showthread.php?t=2178274

http://askubuntu.com/questions/352405/dual-boot-windows-8-and-ubuntu-12-04-irst-ubuntu-not-booting-black-screen

https://01.org/linuxgraphics/node/143

http://ubuntuforums.org/showthread.php?t=1682090

At a Bare Minimum

I've read about 30 - 40 different posts to help figure out my problems.  But, I'll list all of the things that ended up being necessary.

1. Disable quick/fast boot (available in both the bios and windows control panel)

2. Disable secure boot (only available in bios).  For some reason my version of windows and my machine's hardware didn't give me the "UEFI settings" panel in Windows mentioned on this page: http://www.everydaylinuxuser.com/2013/09/install-ubuntu-linux-alongside-windows.html

3. Change the boot order of my drives in the bios.  The bios installed on my machine is MUCH more graphical than I've ever seen before - you actually have to drag and drop the icons representing the drives to the order you need/desire.  It looked like this (see the bottom right section called "Boot Sequence"):

4. I had to use Ubuntu 13 (13.10) instead of 12 (12.04.3) as is mentioned here:

http://askubuntu.com/questions/340223/ubuntu-13-04-on-uefi-system-hangs-at-black-screen

If I used the 12 version instead - it just skipped the GRUB menu and tried to load Ubuntu and I ended just hearing that drum noise/sound and that blinking cursor up in the top left of the screen.

5. When the Ubuntu ISO image is loaded from your USB Drive - you will be presented with the "GRUB Menu".  Select "e" (for edit), then go to the line that starts with "linux" and at the end of that line append "nomodeset" (minus the quotes) onto the end of the line. 

6. boot-repair: Essentially after you complete your installation of Ubuntu - you'll need to run all of this:
https://help.ubuntu.com/community/Boot-Repair


7. Nvidia drivers!  So even after completing the installation and using the above "boot-repair" to fix my install - Ubuntu still wouldn't load.  So I tried the following command:
sudo apt-get install nvidia-current-updates

from here:
https://answers.launchpad.net/ubuntu/+question/236358

in the hopes this would resolve it.  Nada - I still just got the "drum noise" when I restarted my computer without the usb flash inserted.



At this point - when I booted up my PC no GRUB menu would appear - the PC would just load directly into Ubuntu and hit the black screen of death (or display the text "loading initial ramdisk..." - can't remember which) and play the drum noise.  I.E. it had seemed as if I had "bricked" my new computer - as I wasn't even being presented with an option to boot into windows (using the grub menu).

8. I re-booted off the Ubuntu ISO on my USB drive and re-ran boot-repair a second time using these instructions:
https://help.ubuntu.com/community/Boot-Repair

Now this time - when I clicked restart - I saw my first error message:
starting load fallback graphics devices    [fail]

Seems pretty clear - I have a graphics driver issue.  When it did eventually restart - I got the GRUB menu - but there was no option to boot into windows.  


9. However, there was an option to run Ubuntu in "recovery mode" (under "Advanced").  In the "recovery menu" I selected "grub" (next to that entry it says "Update grub bootloader").  Which I presume is the equivalent of entering something like the following at the command prompt:
sudo update-grub
or
sudo update-grub2

I've no idea which version of grub I'm using - I presume two and I think I saw that at the top of the GRUB menu when I last rebooted.

Some text flashed by saying "discovered windows partition on sd1, and so on".  Suddenly my windows partition reappeared on the grub menu - which allowed me to boot back into windows 8 - hurrah!



At this point without a Ubuntu ISO plugged into my USB drive - the grub menu appears and that menu includes an option to boot into windows.  I can also restart my computer, insert my USB drive (with the Ubuntu ISO) and boot from that providing I add the magic "nomodeset" at the end of the line that has linux on it.

In other words - I have yet to actually log into the Ubuntu OS that I so carefully installed on my PC's harddrive.  Best guess right now is that it is my nvidia graphics card.



10. Now after using the following command:
sudo apt-get install nvidia-current

from the website I referenced above:
https://answers.launchpad.net/ubuntu/+question/236358



11. I even tried updating the grub file mentioned here:
http://askubuntu.com/questions/140640/nvidia-drivers-and-kernel-update-problems-nomodeset

And using VI to update the configuration/setting line it mentions to force it to include nomodeset - but the file was read-only and I chickened out on chmod'ing the file - in case that would break something.  Unix and Linux usually mark files as read-only for good reason and I'm simply too ignorant to know if that would break something badly.


12. Then I just went on a "bender" (a little crazy) and loosely followed this page:
http://ubuntuforums.org/showthread.php?t=2161464

Specifically this bit:

sudo add-apt-repository ppa:xorg-edgers/ppa  
sudo apt-get update 
sudo apt-get install nvidia-319 nvidia-settings-319 nvidia-persistenced libvdpau1

But I ended up having to drop the "nvidia-persistenced" from the last command and also prefix that same command with this:

sudo apt-get install nvidia-prime


I'm not really sure what I've done now.

Wild Goose Chase

I also ended up trying a lot of different things that didn't work - which are more important than the things that did work (since you can end up wasting hours - pursuing a dead-end):


1. Don't use the "unebootin" application to mount your ISO on your USB drive - it creates this strange menu, with a 10 second timer and no matter what I chose - the screen would just lock-up/freeze.  The ONLY way I was able to boot into Ubuntu was by using the "Universal USB Installer" (to mount my ISO on my USB drive) - I'd also recommend - always using its format option (of course providing you don't need anything on that disk you've mounted).  By using the UUI - I was given a 3 item menu (try without install, install, check for issues) AND a bunch of options like boot into text-mode and edit.  The edit option followed by the nomodeset on the Linux line was the ONLY way I could boot into Ubuntu on my machine.

2. Don't switch "Boot Mode Selection" from "UEFI and Legacy" or "UEFI" to "Legacy".  This will prevent the GRUB menu from appearing - which I needed in order to add the "nomodeset" to the end of the line that starts with Linux (not kernel) as was alluded to in this post: http://ubuntuforums.org/showthread.php?t=1682090

3. Some disk drives won't be recognized on boot-up.  Try just getting a cheap flash drive (instead of a terabyte or larger external harddrive) - the Ubuntu ISO wants to be loaded onto FAT32 - so a flash drive with anywhere from one gigabyte to 32 gigabytes is all you need.  I used a ten year old ipod shuffle - but you could just as easily use a camera's SD card. 

To Switch to Legacy or Not to Switch to Legacy

This person had success by switching the boot mode from EFI to legacy AND then using boot-repair:
http://askubuntu.com/questions/272728/black-screen-after-grub-cant-install-uefi

But, I think that is more for people who had Ubuntu installed first and then installed windows - but I'm not sure - I don't know anything about the application/tool "boot-repair".  Also I have seen other posts (like mine) cautioning people against switching to Legacy mode:
http://askubuntu.com/questions/374931/install-ubuntu-in-uefi-mode-unable-to-boot-from-usb

Best Online Tutorial for Installing Ubuntu onto Windows 8 Machine
Lastly, the best step-by-step tutorial I found online for someone with windows 8 installed that wants to install Ubuntu is this:
http://www.everydaylinuxuser.com/2013/09/install-ubuntu-linux-alongside-windows.html

I just was blocked for about six hours when he gets to the windows 8 screen that mentions the "UEFI Firmware Settings" - since my version of windows 8 and the underlying hardware/firmware don't seem to support/have/provide it.

You've Run The Ubuntu Installer - So You're Done Right?  Right!?!

Wrong.

General Information

Here is a decent overview of the flag/setting "nomodeset":
http://ubuntuforums.org/showthread.php?t=1613132

The following thread was actually the first thread I found that most closely matched my symptoms and made me wonder if it might be my "new graphics card":
http://askubuntu.com/questions/352405/dual-boot-windows-8-and-ubuntu-12-04-irst-ubuntu-not-booting-black-screen

Again in their situation the use of the tool/application "boot-repair" came up - but I suspect they were starting with a machine with Ubuntu and then installed Windows.  And one last mention of the infamous "boot-repair" application/tool - obviously useful when things go wrong with an existing install of ubuntu:
http://askubuntu.com/questions/257479/ubuntu-wont-boot-from-a-usb-on-my-windows-8-laptop




There was also some useful/interesting information in the following thread - but more about just getting a USB drive bootable on your PC:
http://superuser.com/questions/507111/if-usb-is-not-listed-in-bios-as-a-boot-option-does-that-mean-the-machine-cant

What Prompted This Post

The "Ask Ubuntu" website/forum only allows new users to post two links in their posts - so as you can see - I have a lot more links I wanted to post.  Here is the post with my question:
http://askubuntu.com/questions/413818/new-pc-with-windows-8-needed-nomodeset-to-get-ubuntu-to-load

Your Code is a Joke!

Programmers Aren't Renowned For Their Social Graces

When you first decided to get into the industry of programming you must have already met more than a few people who had obviously gotten into it because they were better interacting with machines than people.  So the unfortunate burden for the rest of us is we need to get along with "those people".  Yes, that's right "those people".  To be fair, we're all on "the spectrum" all the way from social oblivious programmers to social butterfly (much like the autism spectrum).

Does any of the following sound familiar?

• I just rolled back your change-list.
• Why did you bother submitting that [code I had been working on for weeks]?
• I just reverted your code.
• The performance of <insert the tech you own> is terrible/slow.

Now, for clarity - it is perfectly fine to revert/roll-back someone's work - but as a friendly gesture - give them a head's up before you do so.  In the best possible of worlds - you discuss the problem and that gives them an opportunity to address it (thus removing the need to revert it).  Failing the ideal scenario - as a courtesy you just give them a head's up that for some reason (business or technical) you'll need to undo the work they submitted.  And yes, this applies even if you own the system in question.  I realize what I'm about to suggest is common-sense - but just put yourself in their shoes - if you would be annoyed at someone who reverted your work without giving you a head's up first - why wouldn't they?

I've been unfortunate to be on the receiving end of all of the above.  I'd like to say I've never taken it personally, but truth be told - every time I hear or see those words - it bothers me.  As I've gotten older, I've started to take less "personal offense" when someone says (or does these things) - but there is always that initial gut/knee-jerk reaction of "what a so and so" - thankfully people aren't telepathic yet - so this is where you apply the social filter they haven't developed.

When is Being Right More Important Than Successfully Collaborating?

Depending on how deeply you read into this - the answer might not be obvious.  Computer science is one of those domains where there are "strictly better" solutions.  For example a O(n log(n)) is inferior to a linear-solution or O(log(n)).  However, like most domains of sufficient complexity (for example: medical science) - the more interesting the problem, the less obvious the solution.

On the surface, a problem can seem very simple, but more than once I've been surprised to learn of a much deeper problem.  On one occasion I recall updating a method that was exposed through our public API - only to find out from one of our customers that I had dramatically dropped the performance of the application they had built on top of our back-end system.  That was when I learned about the symbiotic relationship you can develop with customers.  The new features/functionality they're requesting are granted a higher priority and they are willing to take our pre-releases/beta's.

The point of all of this is just to say - just because you think you're right, does not make you right.  

Conclusion

When all is said and done - it doesn't matter how perfect and efficiently you've written your code.  More applications (stand-alone, web, database, middleware, etc) have been written than have been "used".  The most "successful"* applications are those that have required the efforts of many programmers working together towards a common end.

Parting Thought

No amount of experimentation can ever prove me right; a single experiment can prove me wrong.

*From my perspective the success of an application is based on how widely used it becomes and how useful it is to those that use it.

Support 101

If it Wasn't Challenging Would it be Rewarding?

And more importantly would anyone pay you to do it?

I hope to create a series of posts about specific support scenarios I've worked through.

The Reward

Supporting a technology can be your most challenging tasks - but I've also found it the most satisfying.  Nothing feels quite as good as showing someone a quick and easy solution to a problem they have using your technology.  Truly it is part of what attracted me to programming in the first place - automating what was once a hard/manual task.

The Unreward

I was tempted to name this section as "the reality" - but in actuality I've had far more rewarding support scenarios than taxing/unsatisfying ones.

Below is an actual transcript I had over communicator with someone who was located in a different city (from where I was working).  To preserve anonymity and stay within the legal boundaries of the NDA's I had signed - I've removed the specifics.  Probably the most important aspects from this communication were:

1. The user expects me to drop everything to answer his questions
2. His questions/messages come so rapidly I'm forced to give him my full attention
1. The frequency of his messages and his lack of clarity also make it clear he hasn't and isn't going to read the documentation I've pointed him at
2. This gives me an indication that he doesn't respect my time as much as his own
3. The user isn't giving this task his full attention and is trying to do more than one thing at a time

The Dialogue

7:44 AM NotGoingToReadTheDocsUser

Sup in PatientProgrammerTech is it easy to add a new ttype to schema?

\Aka I want to [achieve this technical goal].

I was going to hack [the fundamental infrastructure of this tech you own]

9:07 AM Patient Programmer

PatientProgrammerTech has no difficulty with [the technical goal he has]...

Let me see if I can find a good example of that..

[Lengthy explanation with sample code and links to documentation]

9:16 AM NotGoingToReadTheDocsUser

Its not in here at all

Do i add this code somewhere?

9:16 AM Patient Programmer

[Further sample code and explanations]

9:18 AM NotGoingToReadTheDocsUser

the question is where to drop this.

I have PatientProgrammerTech open

9:19 AM Patient Programmer

[Further sample code and explanations]

9:20 AM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

9:20 AM Patient Programmer

[More answers]

9:22 AM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

9:22 AM Patient Programmer

[More answers]

9:22 AM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

9:22 AM Patient Programmer

I don't understand your question... perhaps phone me?

[More back and forth]

9:29 AM Patient Programmer

all configurable...

10:25 AM NotGoingToReadTheDocsUser

will continue this at a later time

I'm flooded with other things for the time being.

10:25 AM Patient Programmer

ditto

1:27 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

2:02 PM Patient Programmer

[More answers]

8:47 AM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

8:48 AM Patient Programmer

we're probably arguing semantics here... but [more technical explanations]... hang on... a tick... I have something you may find enlightening...

8:54 AM NotGoingToReadTheDocsUser

Ok.

I;ll get back with you went i look at this

we have some crazy [unrelated bugs in our application].

9:34 AM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

9:35 AM Patient Programmer

[More answers]

9:36 AM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

9:37 AM Patient Programmer

[More answers]

9:38 AM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

9:40 AM Patient Programmer

[More answers]

9:41 AM NotGoingToReadTheDocsUser

[Additional questions and still not understanding]

9:41 AM Patient Programmer

okay hang on NotGoingToReadTheDocsUser - call me

you're misunderstanding a lot here

[More technical explanations]

9:43 AM NotGoingToReadTheDocsUser

after lunch I have been putting it off.

the other thing is

If I can't solve this thing in a hour I'm going to do some other way for my [technical problem].

9:44 AM Patient Programmer

[More technical explanations]

1:18 PM NotGoingToReadTheDocsUser

Is it possible to explain this to me by text?

becuase I'm looking at a [unrelated bug in our application] and keep getting up from my desk.

1:21 PM Patient Programmer

I can try... but I feel like we're running in circles...
do you have anyone on your team who is PatientProgrammerTech savvy?  Your request is easily handled by PatientProgrammerTech - many teams have done this - I'm not sure what you need that I haven't told you...

1:21 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:22 PM Patient Programmer

okay... so what don't you know that you need to know?

[More technical explanations]

1:24 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:24 PM Patient Programmer

[More technical explanations]

1:25 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:25 PM Patient Programmer

[More technical explanations]

1:26 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:27 PM Patient Programmer

[More technical explanations]

1:27 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:28 PM Patient Programmer

[More technical explanations]

1:28 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:28 PM Patient Programmer

[More technical explanations]

1:28 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:29 PM Patient Programmer

[More technical explanations]

1:30 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

1:30 PM Patient Programmer

[More technical explanations]

1:30 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

Ok. I'm listening

1:31 PM Patient Programmer

[Let him know I've got to get back to the work I've been assigned - but will get back to him immediately after]

1:31 PM NotGoingToReadTheDocsUser

thats fine

1:50 PM Patient Programmer

[More technical explanations]

1:50 PM NotGoingToReadTheDocsUser

I'm sitting on my thumbs for another issue anyways lol

1:50 PM Patient Programmer

[More technical explanations]

1:51 PM NotGoingToReadTheDocsUser

ok.

1:51 PM Patient Programmer

[More technical explanations]

1:55 PM NotGoingToReadTheDocsUser

Pause on that

[Additional questions without having read the documentation links]

1:58 PM Patient Programmer

sent you an email...

1:59 PM NotGoingToReadTheDocsUser

im looking it

and questioning this one thing

[Additional questions without having read the documentation links]

2:00 PM Patient Programmer

[More technical explanations]

2:01 PM NotGoingToReadTheDocsUser

ok...

[Additional questions without having read the documentation links]

2:02 PM Patient Programmer

[More technical explanations]

2:10 PM NotGoingToReadTheDocsUser

[Additional questions without having read the documentation links]

HERES the biggest question i guess

2:15 PM Patient Programmer

I don't mean to offend - but I think you would benefit from a presentation/overview on PatientProgrammerTech... I think you're learning things the hard way... somewhat... backwards...

2:15 PM NotGoingToReadTheDocsUser

[Additional questions consciously ignoring my last suggestion]

2:15 PM Patient Programmer

This is a good starting point:
http://companyintranet/PatientProgrammerTech:Welcome

on the above page there are a couple of good presentations that cover everything I've been telling you

2:18 PM Patient Programmer

this one is a good basic one:
http://CompanyIntranet.com/PatientProgrammerTech/Documents/Default.htm
and the one on the bottom is more advanced

http://CompanyIntranet.com/PatientProgrammerTech/Documents/Advanced.htm

2:19 PM NotGoingToReadTheDocsUser

Your right

you know what the damn problem is?

[Additional questions without having read the documentation links]

2:24 PM Patient Programmer

NotGoingToReadTheDocsUser - I'm going to need you to start looking at the doc's... sorry... but I need to get back to [the project I work on]...

I sent this one to you a while ago - take another peek:
http://companyintranet/PatientProgrammerTech:UseCase[Specific to his scenario]

This is a good overview of how we achieve reflection:
[link]

it is a subsection from this:[related link] 

Conclusion

At the start of the above dialogue I posted one possible reason for this person's distraction - but it could equally be distraction being imposed upon him by coworkers, management, etc:

I'm guessing I'm not the only one that has had to deal with a user that just flat out refused to rtfm - even when you ask politely.  I'm not sure what the moral of the story is here - but probably the best advice I can offer when dealing with "a horse that doesn't want to drink" is to do your best to keep your cool and perhaps give the user the opportunity to do some research on their own.  That isn't to say you should ignore the user - but that also doesn't mean you should reply the minute he sends you an email or a message.  The coddling you give them can make them dependent on it.  As I've heard some people say - "the more you help them, the more you hurt them".  

To Email Or Not To Email

Dealing With Conflict

Inevitably you're going to have disagreements, take objection or receive an email or message from a coworker with a less than pleasant tone.  These situations can be uncomfortable and will likely raise your hackles.  Dealing with a coworker who brings hostility into a textual communication can make your job unpleasant.  Unfortunately your coworker is effectively making their problem yours.

Speak to them in Person

When a communication becomes hostile over email or some messaging application (like communicator, Lync, etc) I recommend asking that person if they have a few minutes to chat in person.  The virtual aspect of email allows people to just say what they think without filtering it through their "public face".  By allowing them to see your face they have to devote more of their attention to the communication and hopefully make them think twice about saying something careless.

Step Away

If talking to the person face to face isn't an option, go ahead and write a reply, then let that email sit for five minutes in an open window, go and do something else (continue working on something else, grab a water, etc) and then go back and re-read the email to ensure it makes sense (reread it for grammar) and only then send it.  Those five minutes (and the context switch) can help you calm down and determine if the reply really is appropriate - remember you're creating a permanent archive of that communication once you send it.  Over a few years of working at the same company - I wrote over 400 draft emails that never made it to their intended recipient(s).


If the issue requires your attention in under five minutes - generally that person won't rely on sending you an email.  One interesting thing you'll notice is providing there is a long list of recipients - someone will reply before you do and quite possibly they'll know something you don't.  

Remove the Audience

One other tactic that can be effective in diffusing a hostile back and forth is to "remove the audience".  That is, reduce the list of recipients down to the smallest set of people that "need the information".  When someone questions your competence over email it will be very tempting to reply to all in an attempt to redeem your maligned reputation.  However, this is likely to only exacerbate the situation - so try to determine if you actually have any useful information to contribute and if so - only to the people who need that information.  

One of the remaining recipient(s) might see fit to "re-add" the audience - that is their prerogative - don't make a point of removing "the audience" repeatedly unless there is a business reason to do so (i.e. confidentiality).  By continuing to remove the "audience" you're defying their decision and you're likely to heighten aggression rather than diffuse it.

Different Sources

There are a few different types of people that can bring aggression into your work life.

Management

This will be the most stressful and difficult to manage.  The most common form of aggression and hostility I've experienced from management has been nagging (AKA micromanagement).  This can take the form of an insistence to know what you're doing on an hour to hour basis, questioning every little decision you make or made, etc.

The complexity in this situation is that management is in a position of authority.  If management has become overbearing or hostile towards you (all the time) then there is already a much deeper problem (than just a moment of poor judgement).  Either you've lost the trust of management and/or you're in the unfortunate position of having a poor manager.  In either of those cases - it might be a good time to start looking for work elsewhere - in the same company or externally.

However, if this is just a "one off situation" (the exception to the rule) rather than "the new normal" - then you have other options.  The important message you need to convey to management is that you enjoy working at your company (even if that isn't true at that precise moment) and want them to know they can rely on you and trust you to deliver on their expectations.

Peers

This is only a slightly better situation than getting hostility from management - since you have to work with these people.  Even if these people don't have authority over you - they still have the ability to make your life unpleasant by sowing seeds of discord against you (with other peers or management).  So just like the situation with management this situation needs to be rectified.

There are too many different types of peer interactions you will have to enumerate all possible responses.  However, from a high level - the important consideration in this situation is whether you're likely to have to work with this person over the long term.  If you won't - then suck it up and move on.  Let them vent and think about the light at the end of the tunnel (your more positive peers).  

If you will have to work with them on an ongoing basis - allow the current situation to play out.  Once the smoke has cleared - I'd recommend "grabbing a coffee" with your peer and make sure they know you're primary concern is providing the most value you can.  Remember part of the reason you're being compensated is to work with others.  Again, I find face to face communication help you both see eye to eye (figurative through the literal).

Customers

As you've probably guessed - getting hostility/aggression from anyone isn't going to help your career or just doing your job.  But, in my experience the easiest of the three sources of aggression to manage is your customers.  These can be internal customers (that work at the same company) or external customers.

Again just like the other types of coworkers - there is no silver bullet for all situations.  In some positions - customers can have a strong influence on your position.  The special aspect of working with customers is that they "need something from you".  Find out why what you're doing isn't meeting their expectations - but do your best to keep that communication professional.  Sometimes, customers just like to complain - so unfortunately you have to play the role of the "complaints department" - sometimes expressions like "unfortunately with our limited resources - this is the nature of the beast" - it tells your customers you have no power to improve the situation.

Conclusion

1. Try to get some facetime with the aggressor - you might even find you misinterpreted the tone of the textual communication.
2. Step away from the computer.  By instantly replying with your knee jerk response - you could just be playing into their hand.  Try saving a draft of your email and ask one of your peers or management if the email is appropriate.
3. Remove the audience.  Who really needs to hear your response?

Talking Yourself Out Of Your Job

Starting Your Career

If you've been programming for over a year - you've probably been assigned a monotonous, unrewarding, menial and/or junior task.  In fact, I'd argue that everyone should start out doing some of these tasks.  Not because everyone should be punished or put through the dreaded "trial by fire".  But, 

1. Every company has this kind of work,
2. It is useful for perspective (to get an appreciation for "good work"), 
3. It is important to understand the basics of where you work and 
4. Lastly - then you'll be able to understand the motivation for building the infrastructure necessary to reduce this sort of work.

A lot of what you learn during the beginning of your career has more to do with learning about how to work with others in a professional setting (i.e. on a real job).  You also learn the basics of the existing technologies at the company, the API's you'll program against, the most commonly used IDE, the source/revision control system (Git, perforce, etc) and so on.

Typically someone will be assigned to you to help get you up and running.  This person will be your "buddy" and you'll likely use them a lot in order to become productive and efficient.  They might even be the person that management uses to find out how well you are doing.  So, it goes without saying you want to make a good impression.

Becoming An Intermediate Programmer

What one company calls an intermediate programmer and what another company calls an intermediate programmer can be as different as comparing an Olympic athlete with a high-school athlete.  Typically larger "professional software" companies like Amazon, Google, Microsoft, etc have a very high standard for their programmers.  Smaller companies or companies whose primary line of business isn't software tend to have lower requirements for reaching the level of an intermediate programmer.

Moving to the level of an intermediate programmer typically requires the ownership and management of one or more technologies.  There might be opportunities for you to provide guidance to others and possibly at the high end of the spectrum to mentor others.

Reaching Senior Programmer

Just like intermediate programmer - there is a wide definition for what a senior programmer does.  Some of the titles given to senior programmers are "senior software engineer", "architect", "technical lead", and so on.  

Moving from intermediate to senior programmer - is much different from the move from beginner to intermediate.  Becoming a senior programmer requires you to be able to accept and manage ambiguity (both in underlying details of tech and in planning), being accountable/responsible for technology and its development, etc.  There is also typically an expectation that you will fulfill a mentor capacity.

Say These Things to Yourself...

The following quotes should be as automatic to you as a mantra or a motto.

"Sorry - I was wrong."

You might want to say it a couple of times to yourself (make it sincere) and accept the fact that on occasion you'll need to swallow your ego and accept you've been wrong.  Now if you can accept you're going to make mistakes, here comes the tough part - accepting it graciously when someone points it out.  

You're going to write some code and you're going to think it is awesome (or at least "good") and guess what - eventually someone on your team is going to point out your code is "wrong".  Now if your code has an obvious bug - taking this criticism is going to be easier to accept.  However, if the person in question just has a different approach (error code versus exception for example) to that problem they might tell you to change it - just to appease them.  And now prepare yourself - if that person is senior to you or if they own that tech - you need to learn that is the "right way".

"I'm Your Man (or Woman)!"

Remember at that bit at the start of this post about being assigned a "monotonous, unrewarding, menial and/or junior task"?  Well - here comes another tough pill to swallow - it doesn't stop the day you become an intermediate programmer.  This is a hard one to accept and one I'm still working on myself.  On that ill fated day when your manager gives you a less than glamorous task that no one else wants to touch with a ten foot pole - do it.  Don't complain, drag your feet or bemoan the fact it has landed on your doorstep.

The important bit here is not just doing the work, but doing it to the best of your ability and accepting that that work happened to be the highest priority task.  Now if you're anything like me - you'll probably ask yourself, but "why me?" - why can't the more junior member of the team do the work?  Well, the truth is they probably could have and you could have continued working on your "more important" work.

But, when management decides to assign someone work - that task is, by definition, not "unimportant work".  Whether you agree with management's prioritization of important work is not relevant.

Now, you might be saying to yourself - "what about my experience, skills and my career progression?".  And these are all valid questions - why was this task assigned to you, why isn't management giving you the more interesting or senior work.

My advice - do the work to the best of your ability and don't complain.  Don't gripe about the work to your peers and certainly don't send an emotionally heated email.  By the way - NEVER do that (send a emotionally charged email) - if an exchange becomes emotional - talk to the person face to face - don't elevate aggression with a pithy reply.  The topic of communication - specifically email is actually significant and important enough that it warrants another post.

Only once you continue to be assigned the least glamorous/interesting work (month after month) should you raise a concern and only with management (don't gossip with your peers).  The important thing here is that you don't react the first time this happens.  When you raise this with management - don't bring emotion or ego to the table - just ask if they're unhappy with your performance lately.  If they're not consciously "picking on you" (they're probably not) mention to them that you'd like the opportunity to work on more interesting features/functionality.

In other words - when presented with this kind of work - you tell them "I can take care of that".

Okay - So What's This "Talking Yourself Out Of Your Job" Business?

Well, the intent of this blog is to try to focus on the softer skills of being a programmer or just working with others in general.

I've been programming for almost 15 years as a salaried employee and most of it has been pretty interesting.  I've had the opportunity to work with a wide range of people (intellects, social skills, cultures, etc).

The summary of this post is the way to progress as a programmer, software developer, software engineer or whatever your profession might be is to meet the expectations of management.  It is okay to disagree with management and your superiors, but if you don't want to "talk yourself out of your job" - do what is asked of you.  You don't understand why people treat you the way they treat you.  Even if your lucky enough to always understand the reasoning behind everything management or a senior person does - your job is to meet their expectations - not yours.

This doesn't mean you shouldn't ever complain or expect to be able to do interesting work.  Quite the opposite - if you "do well by management" - you're increasing the likelihood that you'll be the first person on "who gets this choice bit of work".