i noticed an interesting phenomenon – when talking to a few recent grads or those that are about to graduate, i realized that a lot of the smarter ones are disillusioned about programming.

i find it interesting, because i went through the same transition. having done some pretty cool practical stuff at school, i got quickly bored at my first job, thinking that there was not much new and interesting stuff for me to do.

at one point i recall flipping through the Pragmatic Programmer book right after it came out and dismissing it as something that was too obvious to pay attention to.

i view it as a key telling sign now. this was my own attitude at the time, and i see it again and again in new hires fresh out of college.

being a smart kid, you (perhaps subconsciously) try to assert your own superiority, and perhaps being somewhat defensive, you are all too quick to nod in agreement and move on the moment you think you grasped something.

it turns out that when i go back and re-read some of the books i thought were full of obvious stuff, i discover something that i have learned much later through my own mistakes.

maybe this is the cursed fate of these books – you either read them when it is too late and you wish you read them earlier, or you read them too early and you wonder what all the fuss is about.

what i personally found helpful in this case was the “beginner’s mind” stance – embrace the fact that you know nothing; be humble and view everything that comes your way as a learning opportunity.

which brings me to an opposite learning dysfunction. my first year of university had cryptography, compiler theory, computer languages, two semesters of discrete math, data structures and algorithms, theory of computation, etc, etc (and this was just the CS stuff). it was simply too much for my little brain, so i employed FIFO / LRU eviction approach – without practical application these concepts were promptly forgotten after i passed the exams.

only years later i painfully learned that all of that stuff was actually relevant and important and used in practice. i went back to grad school to patch up the fundamentals and re-learn all of it again at my own pace.

this time around, having done practical stuff, and having established a much broader picture of the CS field, i could finally see how it all connected, and how this knowledge was used in practice.

maybe all of the above is irrelevant to everyone else and could be attributed to my own learning disabilities. however, having worked in corporate IT for past 10+ years, i think there are lessons to be learned for everyone, since those that come out of school have to spend their first year or two learning on the job.

most schools teach computer science which is not the same thing as software engineering. the problem is that the industry needs more software engineers – those that can build everyday quality software and make sure it runs and actually does what the business wants it to do.

sometimes the stuff that you learn in school is directly counterproductive – you work alone and get your own grade; most of the time your work is over once a particular problem or concept is implemented; no one evaluates the quality of design, no one cares whether your stuff is maintainable, or uses version control, or has repeatable builds, etc.

it is up to organizations to make sure that new hires get trained – a mentor/buddy, a stack of books, a pile of wiki entries to get started. it is an investment that requires time and management support.

as for the new hire – be a professional in your field, strive to join the 5% and have fun doing it. otherwise you will be one of those 9 to 5 folks cracking “it is case of mondays” jokes and doing the same thing year after year (well, maybe not, but this is my own personal hell scenario). the field is changing so fast, that you have to keep learning to stay relevant. think of it as climbing the escalator that is going down – the moment you stop climbing, you are falling behind.

there is so much cool stuff out there that is IT-related, and each year it is only getting more interesting. what we need right now is more good engineers with business aptitude to bring in a much needed rigor and professionalism to the field of business software. there is a lot of stuff to do, and hopefully we’ll be able to communicate it to the newcomers.

face the enemy

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil¹

continuing the topic of my previous post (do not deploy black boxes, allow for measurement, metrics, monitoring), i offer you my two rules of performance optimization (heavily optimized for enterprise environment²).

rule #1: don’t do it

i’ve seen more crimes committed against software in the name of performance optimization than for any other reason³.

don’t bother with performance optimization – deliver working software first.

instead of spending time salivating over sexy distributing caching algorithms and debating the merits of lock striping approaches, implement by feature and most likely you will find out that performance is good enough.

a fitting quote from Refactoring:

The secret to fast software, in all but hard real-time contexts, is to write tunable software first and then to tune it for sufficient speed.

i know it is hard to resist the glimmering image of a performance superhero squeezing out a dramatic 100000x speed increase. we are all guilty of dreaming about it. face it – you are not writing hard real-time systems. you’ll just have to buckle up and stick to implementing business functionality without getting to play with those exciting computational problems.

finally, know your requirements upfront – what latency can you actually tolerate, does it even matter? what throughput do you need? make sure you have the actual numbers; both average and worst case scenarios. guess what, in many cases it turns out that you do not need to optimize to begin with.

after all, performance optimization is always about trade offs – leave your options open.

rule #2: don’t do it blindly

measure, then optimize. most of the software spends most of its time in just a fraction of the code – the “hot spot” – find it and optimize it away.

having a well-factored program leads to hotspots that are easier to isolate and optimize.

way too often i see people diving in and tweaking things left and right, just because they think they know where the problems are.

at best you will waste your time, but most likely you will actually make things worse.

if you live in the java platform world, you are in luck – there are so many tools out there for modern JVMs – use them!

notes

rules are meant to be broken, but i’d rather overreact upfront to discourage frivolous optimization.

yes, yes – you have to have basic knowledge so that you do not do stupid things all over the place and end up bleeding to death from a thousand cuts. luckily, in enterprise software most of these things are very basic – a few language rules, and a few design rules – good software developer will follow them automatically.

why performance optimization is so alluring?

here’s my take on it – enterprise software is boring. you’ve done it a few times, and you do not feel like cranking out the same stuff over and over again.

so you start creating complexity to entertain yourself, to give your mind something to chew on: you fall in love with design patterns, you build beautiful multi-tier distributed designs with transactional semantics all over, and you fiddle with performance optimization on every step.

most of us have gone through it; it is like a childhood disease that you suffer from in order to become immune. most of us survived and gained valuable insight in the process. it does take a bit of self-reflection and experience to realize this though.

(those that did not survive ascended to the stratosphere and became raving zombies – and we all know what to do with zombies).

i think the key is to understand that although enterprise software is boring, the vast majority of all software projects still fail. this is where the true complexity is – figuring out how to deliver working software that customers actually use. not to mention doing it on time, on budget, and without burning your team.

this is much harder and at the first sight a lot less sexy, but there are still plenty of technical challenges to work through in order to create well-engineered systems. it is just your definition of “well-engineered” that has to change.

once you re-adjust your focus, the work is cut out for you.

it is tempting to pitch “enterprise” software against the opposite “swing” championed by the pragmatic programmers, rails, and the whole community around it. and of course, it is not the technology but the mindset.

¹ donald knuth paraphrasing hoare

² with apologies to m. a. jackson

³ with apologies to w. a. wulf

i really like this idea of starlets grouplets (as used by googlers) – informal gatherings of people interested in the same topic and willing to dedicate their 20% “extra-curriculum” time to it.

they do not necessarily come from the same team (in fact most of them do not), but they come to work on something together. for some of them it might even become their “main” project.

there are probably half a dozen (at least) small-ish projects at work that i would like to hack on – from an api to a commonly used tool to some improvements to existing tools. this is the stuff that has been created and is maintained by other groups elsewhere, but i have the energy, the ideas, and the expertise to contribute.

the unfortunate thing is that right now it is pretty much impossible (at least with the projects i am interested in). it is not necessarily the direct managerial support – although it would make it easier. i think for motivated people this support does not matter as much – most of the stuff like that i’ve done on my own time as a skunkworks project.

i think the biggest roadblock in my case is the internal culture – people just do not think this way. their first reaction is suspicion and thinly veiled irritation. i understand that this is probably the result of many incompetent people bombarding them with impatient requests, but wouldn’t it be nice, if i simply could check out some code, tinker with it, and then submit a patch? and have someone answer my question or two? it would immediately help some of my daily activities, and benefit others. sort of like the way open source projects are – scratch my own itch and help others in the process.

perhaps, one of the first steps is to make it easier – open up source control, do not require one to chew through the permissions/requests muck to get access to code/environments, start an area on an internal forum (you got one, right?) and an area in an internal wiki (you got one, right?).

most of it will benefit you, but also allow others to come in and contribute. in fact, most of the stuff that can be done is simply a copy of best practices by open source projects.

speaking of motivation, this article by esther derby that muness pointed out to me a while ago is quite appropriate. here’s a quote:

Most people show up for a new job with high motivation. They’re excited and they want to do a good job. But as the weeks pass, motivation dribbles away. It’s not because managers are failing to motivate these once-enthusiastic people. It’s because organizational systems, policies-and yes, management actions-actively demotivate people.

sadly, i’ve seen this happen over and over again.

this time with the newcomer is quite special – take advantage of it (or cultivate it, if possible). they have a perspective and the motivation that might disappear later. they can bring in the new ideas, point out something you’ve never thought of, or simply challenge the status quo. this sort of disruptive energy is very healthy and should happen on regular basis… just stop demotivating me! (sorry, i could not resist – the article title is way too catchy)

well, actually, excitement matters.

in particular, how do you motivate people to contribute; to write that dreaded documentation, for instance?

perhaps one thing worth trying is appealing to the geeky side and giving them(us) toys tools that tap into intrinsic motivations.

in my experience it turns out that if output looks pretty and is immediately available (and especially instantly viewable by others) – people are motivated to tinker and create. in fact, this is precisely the stuff that made internet happen.

to reiterate – instant turn-around and aesthetically pleasing results will take you a long way. probably somewhat related, but better worded – optimize for happiness.

this post is brought to you by the scars and bruises acquired by yours truly as i crawl away from a slow and beaten up twiki instance (that looks like something designed by that stoic mosaic folk back in the day; man, i can hear the sound of knuckles scraping the floor).

looking back i am surprised at how little importance i saw in the process of interviewing the interviewer.

it’s pretty simple – for me the main criterion is how good the people are that i will be working with. they have to be better than me, and i have to be able to learn from them. once this is in place, everything else does not matter as much.

it would be ideal to work on a great project, but even given a bad project, good people can make it worthwhile.

how do you recognize great people? well, i wrote about it before. everything else is icing – useful, but not a replacement for the good people.

ideally, you already know them – user groups, conferences, friends, books, mailing lists, or you simply worked with them in the past. this is how it should be – you are setting out to work with people you look up to on the projects that interest you.

disclaimers galore: mid size to big company, certain amount of evilness is expected and tolerated for a greater goal. this is mostly a memory crutch for myself (i actually had it written down and would whip it out during the interviews).

personal

• how long have you worked here
• why did you come to this company
• what is some of the cool stuff that you are proud of
• why do you like it here
• what do you dislike about working here (blunt, but you’d be surprised what people blurt out)
• your background (education, previous companies, interests)
• top challenge you are struggling with right now

i had a prospective manager interview me once, and he kept telling me how boring the job was, and how stupid the users were, and how underpaid i would be. while i appreciated the frankness, i could not believe that he expected me to take up a job after such introduction. the whole concept of marketing your company to a prospective employee apparently never even entered the picture.

working conditions

• make sure you see where you will sit (i know i was ashamed to show prospective employees around; at least we had aeron chairs!)
• developer setup – monitors, machine, software installs, certain tools
• what does it take to get software (purchased, installed)
• do you get admin rights on your machine. can you install wireshark/vmware/cygwin/firefox and plugins/etc

team

in general i am after gelled teams – those that know each others’ strength and weaknesses, those that figured out how they can work together and get stuff done. those that simply have fun

• i want to talk to people i will be working with (often people from other teams interview you, and then you end up working with another set of people you’ve never talked to)
• collaboration – does everyone hide their little piles of documents on shared drives and guard them, or is it wiki, company-wide forums, at least sharepoint for the team? how do people share knowledge, within the group and between the groups?
• team culture – everyone for themselves or are they out to learn, help, share
• does team eat lunch together (i found it a pretty good indicator of how well people gel, and i always tried to get people to have lunch together at least once a week)
• day in life

org

• org chart – make sure you know who you are reporting to, who is your boss reporting to, where you fit on the org chart. it might seem silly, but if you are out to get stuff done and you work for a bigger company it matters what your actual title is. after you are hired it might turn out that you have landed at the bottom step of the ladder. that shiny title you got was just that – a title, meanwhile it is your actual pay grade that drives the salary and to an extent how much clout you get. once you are hired, it is much, much harder chew your way through, because then you are subject to the usual organizational inertia, policies, etc, etc. negotiate upfront!
• schedule flexibility (can i work from home?)
• do you expect me to work weekends
• how many hours is the team currently working
• dress code
• what does it take to get stuff done (get a new app/tool up and running in prod, roll your own monitoring, push through an idea, etc)
• mobility within company (in most places HR has a policy that you have to work for a year or more in the position you have been hired for before you can move; is mobility tolerated? encouraged? do they care?)
• growing people – training (books, classes, conferences, tuition reimbursement)
• top org problem you’ve got right now (they might balk, but they might reveal something interesting)
• turnover rate (could be very telling) – how long each of the person you talked to have been with the company, how many people leave
• career path – where can i go, what can i do, how can i move within the company, what are the options, what is the organizational chart like, what is being done to help understand it and climb it. i do not quite trust overly formal you-do-this-you-get-that approach (see Steve McConnell, for instance), but it is helpful to know where you stand and what it takes to grow

in addition, i really like the idea of mentorship – assigning a mentor to a new hire. ideally it happens naturally (in a nurturing and caring team), but it would help to make it a recognized practice. it would be someone with significant experience in the industry and in the company; this person will help to “bootstrap” the new hire (in the ways HR never could) as well as help them navigate the company and grow. having a fellow employee in this role as opposed to an HR generalist will be much more effective.

software development cycle

• source control, automated builds, tests
• qa people
• what sort of testing is done
• how are the requirements gathered and tracked
• how are defects and enhancements gathered and tracked
• how is development organized – timeboxed iterations? waterfall? chaos?
• infrastructure – how much access do you have, who runs it
• monitoring
• automated deploys
• how are releases promoted to prod
• support (be careful here – it might end up in a rabbit hole into the never-ending infrastructure improvements and tweakage – late-night pager fire drills and other joys. i believe in eating your own dog food when it comes to running your own stuff, but this is different from looking after the apps that someone else develops. if you are after a developer’s position, clarify the amount of support the team is doing currently and expects you to do)
• are people proactively fixing things and constantly improving, or is that discouraged (heavily regulated complicated development, throw over the wall support (especially if it is offshored), people just do not care, etc)
• what happens at the end of the project (retrospective? what happens to the team? i want to see the team gel and remain together for the next project)
• code reviews (encouraged? non-existent?)
• who maintains the app once it is live
• how are standards created and maintained
• how are best practices disseminated (arch review board with astronauts? hands-on architects? workshops? training?)

current project

• make sure you understand what you are being hired for – that new spiffy project might never materialize
• where will this project be in a year (could it be one of those “pump and dump” gigs, where you are merely a body to be used and disposed of at the end?)

other

• what are you looking for in the ideal candidate

this last one is interesting. it took me a while to realize that (surprise, surprise!) i simply might not be someone they are looking for.

i noticed that being interviewed puts me in a mode where i am trying so hard to be liked, to please the interviewer. this is certainly natural, but quickly becomes evil, if not held in check (“yes, i would love doing 24/7 support for that cobol app written by mental asylum patients during their work therapy course twenty years ago”).

it is simply counterproductive for both of us. yes, this is a job they’ve got, and yes, it is important, and someone has to do it. indeed, i could do it, just like i could do a myriad other things, but i am after something else. this is perfectly OK, unless you are desperate, of course. and this is where the trick is – know what you are worth and always remember what is important to you and what you are after.

a quote from marc andreessen:

most people who do great things are doing them for the first time

this is from an excellent “The Pmarca Guide to Startups” series on his blog

from workatjelly.com (via amit gupta through seth godin):

What is Jelly? Every other Thursday, we invite people to work from our home for the day. We provide chairs and sofas, wireless internet, and interesting people to talk to, collaborate with, and bounce ideas off of. You bring a laptop (or whatever you need to get work done) and a friendly disposition.

as i mentioned before, sometimes i do need people around to be more creative, think stuff through, or simply guard me from distractions (no matter how unintuitive this might sound!). unfortunately, i do not see an abundance of laid-back coffee-shops in manhattan. i also like working at friends’ places (sometimes only because i am too lazy to clean my own!). i am not a freelancer, but i can see how one would need to get out if working from home full-time.

so this is a great idea. even if i cannot make it to this particular incarnation, it is something to keep in mind.

it seems to be a bit different from the “established” co-working (coworking.info, for instance), because it is more personal – our home, not a communal place.

as an addendum to previous post: although i mentioned one of the johanna rothman’s articles in the list of links, she really warrants a separate mention.

i really, really liked her manage it! book (published by pragmatic programmers). at first it seemed a bit dry, compared to weinberg’s writing (he contributes an introduction), but the feeling goes away after a few chapters.

i just feel so comfortable with her take on project management – there is no agilist zealotry or flashy theatrics. she is indeed very pragmatic – she acknowledges different organizations and different projects and teams, she introduces options and alternatives and explains the reasons for each. there are practical tips as well as a larger overall motifs that drive them.

but back to subject of this post – a few weekends ago i spent a whole day combing through her excellent hiring technical people blog. once again, it is perfectly pragmatic, i especially enjoy her style as she explores the ideas, not necessarily presenting them as truths handed down from above.

compare this with joel – he recently cleaned up and released his writing on hiring (smart and gets things done – which i already purchased). i really appreciate many of his ideas, and i think he’s done a great service to the industry by popularizing them, but i do not find myself trusting him fully as a reader – there is too much glitz and posturing, desire to shock and awe. plus he keeps forgetting about being humble – he is an owner of a boutique software company – he is damn good at what he does, but it means just that.

in any case, i have ordered johanna’s book on hiring technical people. she also co-authored another book on project management from pragprogs – behind closed doors: secrets of great management, which i am yet to read.

finally, her site contains another blog on project management, as well as a collection of articles, links to her guest blogs on other sites, etc. she is also a regular at annual amplifying your effectiveness conference, which i really should be going to.

this is something transferred from an internal wiki; i just finished "professional software development" at the time and some of its ideas found their way into the post. granted this is mostly talk, and the hardest part (the skill and the art!) is actually being able to sense all of this in a conversation. usual disclaimers - this was an architecture team for a big company, but suspend all the negative connotations associated with the title (this by itself is a topic for a whole post).

another disclaimer: our technical problems were not that hard at all, so we needed someone with solid CS background and software engineering background (source control, testing, builds, etc). everything else technology-wise is easy to teach, given the right personality. which means that in our case personality is far more important that any skills above the basic ones.

what we are looking for: in general

• hands-on
• strong current technical skills
• solid technical foundation (CS/engineering/years of various hands-on)
• wide breadth of knowledge and experience
• ability to see direction, high-level design, and at the same time to be able and jump in to do development/troubleshooting. naturally people will be skewed one or the other way, but presence of both is important
• passion - they do this stuff in their spare time, they read blogs/articles, they buy books, they go to conferences; they are excited to babble about it
• smart (do not create busy work and slave for 24/7; ask me about "pray-and-rerun for 72 hrs" some time)
• gets stuff done (ability to drive stuff to completion, not just fluffy ideas)
• good match for the team culturally (openness, desire to share and learn)
• self-starter - actively seek solutions, actively challenge status quo
• learns fast
• fast-paced
• balance of operations/design/architecture/implementation/support/business knowledge
• articulate (can explain a bigger picture for the project they've worked on; can explain complex concepts at high-level, easy to talk to, etc)

here's a little personal observation regarding the last point - past few months i've been on both sides of the interviewing fence and it is interesting to note that with good people the conversation just flows - infact during some of the interviews i come up with some interesting ideas as i am talking through things - the sparks fly, the air sizzles, and i am truly enjoying it, no matter which side of the table i am on. at the same time with stupidthicker people i find myself getting dumber and dumber - i start stuttering, repeating myself, going into unnecessary details, eventualy getting frustrated and discouraged. i know it is a problem of mine to an extent, but i think over the years i have come to treat it as a rather objective indicator of how well a person can fit in a team with me.

what we are looking for: great designers

• have a list of patterns they can apply to solve problems (they've been around the block a few times and know a few things)
• mastery of their toolset (they have a toolset, they know what to use when, and they actually do it)
• seek out criticism (do not hide in the corner and spew binaries from time to time - they come out into the open and demand feedback)
• strive to reduce complexity (make it as simple as possible, so that bugs have nowhere to hide; this is a great skill and i am fortunate to know a few folks that truly shine at it, cutting through layers of bullshit and communication problems)
• have experience on failed projects and made a point to learn from it (or any mistakes - true learning does not come from the manuals that teach you how things are supposed to work, but from real life lessons that teach you when stuff does not work and why)
• have a lot of alternatives, often wrong, but quickly correct themselves (a great designer should be able to generate ideas)
• they keep trying alternatives even when others have given up - i.e. do not give up easily or settle with "this would do" - drive to completion, try other options (this is a great trait and i often have to kick myself to strive for it)
• not afraid of using brute force (i.e. pragmatic)
• creative to be able to generate numerous solutions (didn't i just say that above?)
• curious (must always try to learn, figure out how things work, research, investigate, never settle for "someone else knows how it works" - always ask questions; this could be one of the single most important traits)
• high energy (not sleepy, lazy - driven to get stuff done; also see curiosity)
• self-confident and independent to research things that others think are silly, unworkable, foolish (i've been burned by this)
• have and value their own judgment (see above) - never refer to "this is what someone else told me, or this is not my fault, this is what i have been told" but never made an effort to verify
• restless desire to create - build things, make things work, figure things out, tinker
• not satisfied to merely learn facts - but driven to apply them (sometimes i catch myself doing just that)
• no lone heroes - we need those that can raise the value of a team, work with others, be open (share their knowledge, willing to teach, to educate, and to be taught and educated). ''according to many studies the greatest contributor to overall prductivity was team cohesiveness, not the individual heroes'' says mr. mcconnell (also, keep in mind the bus factor)
• community involvement (reading books, publications, blogs, magazines, attending and speaking at a conferences) - all of it is a sign of a commitment, treating this as a profession which does require life-long learning (so in the end it is merely a sign of professionalism, not something that is out of the ordinary); of course beware of talkers that do just that
• do not fall into complacency - always strive to improve (too many that would not challenge themselves and others, settle down)

related reading

• http://steve-yegge.blogspot.com/2006/03/truth-about-interviewing.html
• http://steve.yegge.googlepages.com/google-secret-weapon
• http://steve.yegge.googlepages.com/five-essential-phone-screen-questions
• http://steve.yegge.googlepages.com/what-you-need-to-know
• http://steve.yegge.googlepages.com/why-phone-screens-matter
• http://steve.yegge.googlepages.com/miracle-interview

• http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
• http://www.joelonsoftware.com/articles/ThePhoneScreen.html
• http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html
• http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html
• http://www.joelonsoftware.com/articles/ResumeRead.html
• http://www.joelonsoftware.com/articles/HighNotes.html
• http://www.joelonsoftware.com/articles/SortingResumes.html

• http://www.artima.com/wbc/interprogP.html

• http://software.ericsink.com/bos/Hazards_of_Hiring.html
• http://software.ericsink.com/entries/No_Great_Hackers.html

• http://www.paulgraham.com/hiring.html

• http://blog.guykawasaki.com/2006/01/the_art_of_recr.html
• http://blog.guykawasaki.com/2006/03/the_art_of_recr.html
• http://blog.guykawasaki.com/2006/08/the_inside_scoo.html

• http://googleresearch.blogspot.com/2006/03/hiring-lake-wobegon-strategy.html

• http://hiring.inc.com/columns/jrothman/20050412.html

• http://www.scottberkun.com/essays/39-how-to-interview-and-hire-people/

• http://sethgodin.typepad.com/seths_blog/2006/09/the_end_of_the_.html

i came to realize it gradually over the course of past few years, but i could not quite articulate it until i read this passage in "slack" by tom demarco:

Surprisingly, the stars approached their work in ways that were not very different from the ways their peers did. As a purely mechanical matter, they did the same work pretty much the same way as everyone else. But there were marked differences in how they managed their networks of connections, liaisons to fellow workers whose cooperation was required to get anything done. For example, people tended to return the stars' telephone calls much more quickly. So a star, on average, would receive answers in twenty minutes, while the norm for the whole laboratory was more like four hours. Why did they get better attention from coworkers and colleagues? There was no obvious answer, but they did. Clearly, the stars had long before taken whatever steps were necessary to establish good connections. They had spread around favors, been responsive themselves, nursed relationships, seen to other people's essential human needs.

granted, all disclaimers apply - one has to work in a role that requires interaction with other people to get stuff done, the organization should be large enough, etc.

my experience confirms this - in large organizations you have to know the right people to get stuff done. in my recent role i was fortunate enough to get into the team where i acquired the connections in a span of several months. then you just maintain those relationships: be sincere, make it natural (and believe it!) - you do favors for people because you care about the stuff they need to get done, and only subsequently they reciprocate (perhaps i am too sensitive to this, but it is nails-on-the-chalkboard obvious when folks are shmoozing and try to conceal it; in which case it takes a certain charisma to get away with it).

the reality is that in large organizations no matter what process-improving application/organization is in place, unless you know the people, you will struggle to get anything done. with the right people in place the process is useful, but merely as a documentation/fallback/cya/retrospecting device that is parallel to actual work (disclaimer: given highly motivated, conscious, caring people).

i've seen both ends of the spectrum with new people - folks that managed to piss everyone off in their first few days and then were left in the vacuum; others that were unfortunate to end up in a team that did not proactively and eagerly grow their novice; this is why we made a point to provide as much support as possible for our (welcome) new hires in order for them to establish these relationships (e.g. proudly introduce them as members of our team, bootstrap them with piles of wiki entries that include addresses and names among other things).

ideally, of course, process will be reduced to become as effective as possible, just like personal connections will be a benefit, but not a requirement for getting stuff done. perhaps it is just a corporate aberration; in any case it took me a while to actually consciously acknowledge its importance.

I am a little concerned that this space does not see much of the technical content in past few months. One of the main reasons is that the stuff I spend most of my energy on (and also the area where I currently learn the most) is organizational - everything from project delivery to team dynamics. It is surprising how much of it is dysfunctional, so all the reading that I have done in the past and seemed only marginally applicable now becomes incredibly relevant, supported by real-life examples.

One of the books I really enjoyed recently was Jerry Weinberg's "Becoming a Technical Leader." Very down-to-earth and personal book that is pragmatic, relevant, and simply rings true. Here's a couple quotes:

So perhaps a better leadership question is this:

If you had to take a trip with someone else driving, would you prefer a driver who

1. has never had an accident, but would likely be indecisive if an accident occured
2. has had an average of one accident a week, but was very adept at making decisions in emergency situations

Sad to say, many people seem to prefer (2). That's why Armistice Day has been replaced by Veterans Day. Peace is more difficult to organize, but war is more heroic. Really good organizing seems to lack drama.

Why is it that we reward programmers who work all night to remove the errors they put into their programs, or managers who make drastic organizational changes to resolve the crises their poor management has created? Why not reward the programmers who design so well that they don't have dramatic errors, and managers whose organizations stay out of crisis mode?

Organizing is not about solving problems, but avoiding them. Once you're in the throes of the problem, it's too late to do really effective organizing. Perhaps the biggest obstacle to effective organizing is our eagerness to reward ineffective organizing.

And another one:

A problem-solving leader's entire orientation is toward creating an environment in which everyone can be solving problems, making decisions, and implementing those decisions, rather than personally solving problems, making decisions, and implementing those decisions.

This is where I probably struggle the most in my current team (for many reasons) - giving away trust to acquire trust; in other words, delegating (the book has a whole chapter on it).

Weinberg's "Secrets of Consulting" is next (kudos to Muness for pointing him out to me).

i think it was rutherford that upon noticing that one of his students spent all his time at the laboratory experimenting, exclaimed, "but when do you think?"

work feels like a rat race these days, and i almost have no time to catch up with blogosphere, let alone spend some time playing with things that are interesting and somewhat unrelated (interestingly most of the stuff that i am proud of at work, the stuff that is actually cool, i did as a skunkwork project in my spare time).

i am glad to report though, that i finally found a way to listen to podcasts. ideally it would be during commute or walks at lunch time, but since the city is small and walking around suburban expanse of parking lot is anything but inspiring, i had to come up with something else. it turns out that podcasts work wonders at the gym.

my problem is that these days i get too easily distracted, so confining myself to the tedium of a workout is the best way to focus. it used to be like that before, where i could think through designs or really listen to music, but i never made the leap to podcasts (or audiobooks) until past few months.

i need this time alone, this almost meditation-like state where it is just me and one subject/object that i am dealing with. this is the time when i get ideas, when i am creative. as long as i complement this with regular feedback from others, this is a perfect combination. speaking of feedback from others - it is best to get the team to eat together; it is amazing how well it works not just for bouncing ideas off each other, but for the overall health of the group.

at home achieving this state of concentration is often difficult, since at the same time there are too many distractions, and not enough difference to be inspiring. it turns out that these moment of solitude are most productive when offset by the din of the coffee shop, or even a bar - this way any distraction is short-lived.

at work not having an office, or even a cubicle until recently results in constant context-switching (or even thrashing, when operation duties of looking after others' code clash with any design/building). so i am trying to minimize distractions as much as i can, maximizing the time "in the flow"; it starts with simple things - on my machine all the interfaces are as ambient as possible - no popus, no sounds; but most often i work from home if i want to get anything done.

but back to podcasts - so far i have been catching up with jon udell and itconversations. jon's stuff is always a pleasure - sometimes i rewind and replay just to get everything, sometimes i pause and think - even if the topic itself is not that interesting, or the interviewee is not particularly impressive, jon always finds a way to trigger a thought, providing this inspiring jolt of ideas and connections.

i tried a few channel9 podcasts, but they were sickeningly patronizing and so bland and boring that i switch off in just a few minutes (i cringe easily so any kind of off-color jovial behavior rubs me the wrong way; i can barely take the elevator music and soothing radio-voice introductions of itconversations as it is). now that jon is joining channel9 at microsoft, i am looking forward to their improvement.

now i just need to broaden my search and see if there are any other podcasts worthy of interest (and i guess they do not have to be it-specific, as long as they are spoken word).

So here I am, taking a break from updating my resume. I must say I do feel a subtle streak of vengeance; even though fully acknowledging the childish nature of it.

I think past few months proved to be a good experience; they showed me what happens if there was nothing but work in my life. Not only my world condenses and becomes a tunnel, but even the work itself starts to suffer as I dutifully plug away without ability to step back, look around and get that much needed "blow your mind" experience that ultimately makes me better at my daytime job.

I stopped reading, I stopped actually listening to music, I spent less time on film, on my friends, even on just forgetting the work for a day. The last drop was dreaming about work in those few hours between the urgent phone calls.

Work is not my life, it is something I like doing, it also happens to be my hobby, but it can only co-exist with all the other stuff I am into. I do tend to go into these intensely focused streaks with all my hobbies, but they last for a few weeks, and then I switch.

Working 12-14 hour days without holidays or days off for past two months got me burned out. Occasional sprints at the end of the release are perfectly normal, but they cannot last for more than a week or two.

I am also done with being on-call. I spent 6 years carrying a pager; someone has to do it, but I value my free time too much to get into it again (especially since we are not paid overtime, nor we are paid extra for being on call).

Work seems to be calming down, but the problem is that the most I can expect at the end is a ~1K bonus - all the sacrifices will be forgotten. I have three weeks of vacation left and probably another two weeks of comp time accumulated in past two months, but I know I will be lucky even if I get to take my full vacation (and only one day gets carried over to the next year). This particular situation is not the first time it happened to me at this company. The higher-ups forget too fast and move on, while their people at best get a humiliating trinket.

There is no carrot dangling in front of me in the form of a promotion or a big bonus; no matter how little I think about pop behaviorism that drives popular incentive programs, no matter how much I value my peers' opinion and personal satisfaction, I also want to see recognition for my work and see myself grow.

Another problem is that a lot of the work lately has been firefighting. As any big company knows, the work distribution is 80/20, and we are part of that 20 percent that gets stuff done. We found ourselves in the middle of a shitstorm caused by a big-bang deployment, as it is transitioning from consultants to employees and stabilizes.

There are a lot of things I have learned and learning every day, and it is a big project with a lot of complex constantly moving parts.

However, I find that most of my time is spent managing the communication explosion that is the result of several hundred people working in a large organization burdened with compliance requirements among other heavyweight bureaucracy (just ask me about our laptops). How can I work on anything when I get 300+ emails a day?!

Paul Graham yet again phrases these obvious things very nicely in "Power of the Marginal" while talking about anti-tests:

Where the method of selecting the elite is thoroughly corrupt, most of the good people will be outsiders. [...] If it's corrupt enough, a test becomes an anti-test, filtering out the people it should select by making them to do things only the wrong people would do. [...] For example, rising up through the hierarchy of the average big company demands an attention to politics few thoughtful people could spare.

[...] People at big companies don't realize the extent to which they live in an environment that is one large, ongoing test for the wrong qualities.

It is getting better, and I am getting better at it, and there are nuggets of value in this, but the question is whether I am willing to spend my time and energy on defeating these tidal waves of crap in order to get my work done and gain knowledge.

If I were to stay I would have to play the system in order to advance. No matter how much you help your peers or their direct management across the enterprise, my next title depends on the visibility to the higher-ups, all of those that sit on the promotion board. This means I need to pick something very visible, focus on it, and dazzle them with reporting skills, generating as much noise as possible. Looking around, very few of the folks at this level deserve the title at all (but those that do are exceptional, and I am so glad I have them around, since I can look up to them).

For the first time in quite some time I really do like and respect my teammates and my manager; I think we have a fantastic team with a lot of potential, and the future in half a year or a year looks pretty nice as we are stabilizing the environments, gaining first-hand support and implementation knowledge, positioning the team to be the integration/best practices nerve center that possesses overall understanding of data/systems, their problems/shortcomings, overall design, and, most importantly, the actual knowledge of the way the business works.

What I am afraid of is "boiling the frog" mode, the perpetual dangling carrot of extra bonus, another small interesting project, yet another short-term treat. This instant gratification masks the opportunity costs of not leaving, and these costs are growing every day.

I value loyalty, I like the people I work with, and I know I will be letting them down If I leave, but in the end I do not want to count on company's loyalty when they make business decisions. I have no illusions, and I'd rather be a professional in a slightly different sense that pays less attention to emotional attachments and focuses on more pragmatic things. I think I can do better given my current work environment, my pay, and work hours, compared to other companies.

I am also a little leery of using blackmail tactics to get what I need (threatening to quit or bringing an offer from elsewhere without an intent to accept it). Unfortunately, this seems the only other way to advance in this company without "playing the system".

The time is right. I feel like I need to move on, and changing jobs is more of an excuse to try and change everything else (and this is what it should be, really - a hobby that also pays for the means to do other things). Now it is time to refresh some of the knowledge in preparation for the (anti) tests that most of the interviewers subject people to :)

how do you know that an IT department has failed? when the users, after repeated requests to help them out with building a small custom content management system, turn around, get a server at ev1 servers, and build their app there.

now just stop and think about that for a second. this is just insane! i felt ashamed (of my department, my profession, my title) when i heard about it (especially since my title does have the words "architect" and "enterprise" in it). business users wielding developer tools, trying to replace email chains with spreadsheet attachments, and an IT department that is so bent on "enterprise" and "no more custom development, all packaged products!", that it fails to see a direct immediate need that could be easily filled with just a few weeks of quick hacking in something like coldfusion (or even java, or less "enterprise-y" php/rails for that matter).

granted, if each department goes off and builds their own silos with custom apps, this would be a disaster (ms access app that lives on a shared drive), and the other extreme is true - packages for everything, no more custom development; all or nothing - big bang enterprise solution or email and spreadsheets.

now without knowing all the details, the ideal scenario would have been for the enterprise integration architecture dudes to built a universal standard layer to access enterprise data, and then let the departmental teams go nuts with their own stuff, as long as they conform to a loose set of guidelines on architecture for their apps - supported platforms, some development standards, hands-on enterprise architect on a project, etc. a lot of this department-level stuff should be developed in rapid prototyping language - something scripting, something that is web-enabled, and something that can get things solved fast. the danger is a quick sprawl of spaghetti, and this is where good internal dev teams are important - mentoring, common code ownership, etc. i have seen over and over again how quick rapid app thrown in gets the biggest bang for the effort spent, so we just need to make sure we get the core backend right, and then build systems smarter.

in the interim, perhaps they could have looked at a wiki like confluence, or even at sharepoint+infopath combo that is sadly grossly misused and abused here, but has so much potential, no matter how much i hate standalone sharepoint (probably for all the wasted potential).

we used a lot of cold fusion back in the day, and now the swing is into the Java world and people stopped developing the apps as much as they used to, because the barrier for entry is so high with java. some of it was the backlash against poor developers writing unmanageable apps in cold fusion, but the benefit was an ability to build things fast to help the users. we need to bring this back, but be smarter about integration points with enterprise data. those should be architected/engineered properly, but smaller departmental apps should be built on top of them using glue languages and lighter technologies that lend themselves well to continuous evolution (because, as we know it, the application is never "done"; it is finished only when users stop using it).

i think this is why i am so sensitive to the "architecture astronaut" syndrome; we need to be able to see the big picture, but focus on the end users, "empower" and "enlighten" the developer "masses" that are closer to the business, help them build faster, smarter apps that get the work done. i know i lack a lot of knowledge in the custom app space for this industry, and a lot of the problems are already solved by these large packages, but there will always be the need for something smaller, quicker, more agile built on top of these large enterprise apps that would greatly benefit small groups of users.