manual override

Posted by anton
on Thursday, January 29, 2009

there is something i noticed about myself – oftentimes, when faced with a problem, i immediately jump to the technical means of solving it, which usually implies building some sort of automation. after that jump, the initial problem becomes less and less important, while i am speeding away, thinking through the technical details.

it turns out that sometimes an excel spreadsheet and a manual process is far superior solution, although it might hurt your ego and make you feel vaguely dirty.

another variation of the above is fascination with “cool” tech (for your definition of “cool”) – i noticed that sometimes i would use every opportunity to startup wireshark or Process Monitor and gloriously wallow in data, gleefully probing tiniest details. it turns out that almost always there are better tools out there that can get the job done with less noise.

so as a personal first-line defense, i opt for trying to ask the right questions early on – perhaps a manual solution would do, or a problem really is a non-issue.

it seems that too much knowledge may be a curse, but the real challenge is to keep your personal toolbox organized.

elevator test

Posted by anton
on Thursday, January 29, 2009

building software for a business, i established an interesting test that shows me whether i am thinking in the right direction:

off the top of your head name five most important things that technology can improve for the business as it is right now

i’ll wait – can you do it? right here, on the spot?

the way i see it – if, after having worked in a new team for a few months, you cannot do it – you have failed. you are not thinking about the business, you do not know the business, you do not care.

as technologists we are all too often drawn to the technical problems, forgetting that it is really the business that we should have in mind. the catch is that the domain of the software problems is infinite, so one can submerge forever without delivering anything of value to the business.

disclaimers apply, of course – it particularly matters for those developers working closely with the business. but then your definition of “business” might vary; the point is that sometimes a correct technical solution is the wrong one.

so while you are at it, type up this list and stick it somewhere visible, so that you can have it in front of you every day (as i’ve talked about it before).

go with the flow

Posted by anton
on Monday, January 05, 2009

a damn nice quote from Eric Brechner’s I. M. Wright "Hard Code" blog regarding team dynamics, specifically about retaining people:

[...] the best way to deal with turnover is to expect it and embrace it. How? Think flow, flow, floooooooow.

Think of your team as a river instead of a lake. A lake stagnates. There’s no energy or impetus to change. The same is true of groups that stagnate. They cultivate mediocrity and complacency; they abhor risk. A river is always running and changing with lots of great energy. You want a river.

a nice metaphor and it strikes a chord – building an ideal team is one thing, but perhaps it is more about building a self-sustaining culture when individuals might be coming and going. the latter seems to be a more important goal in the long run.


Posted by anton
on Friday, August 22, 2008

this is a bit of a wandering post, but i know i think best through writing things out, and while personal journals are a great thing, i cannot force myself to write them if there is no (even hypothetical) audience.

i think as i get older, i realize that there is so much stuff out there that i am interested in, that the importance of focusing is becoming increasingly apparent.

the distractions are getting more targeted and more fine-grained – it is getting simpler to fill up all the cracks of time between activities – reddit, twitter, google reader – scan the headlines while you are waiting for the build, and boom – you’ve blown your stack and lost the context. this is when discipline often loses to muscle memory; i suppose it is the usual story of combating the addiction. all this technology i surround myself with to be more effective just makes it simpler to waste time without achieving anything.

in this sense (all other things being equal), i find pair programming to be very helpful – it is so much harder to get distracted with someone else sitting next to you.

in certain cases i’ve observed that the proverbial order of magnitude difference in productivity between individual developers can simply be attributed to the ability to focus.

this became even more apparent to me in the past year at work as i have been faced with thousands of stored procedures for a given system – some of these storprocs being 2K+ lines long and recursive(!). talking about a new level of immersion!

one behavior i am guilty of is perfectionism in the face of overarching bigger goals – trying to make something flawless all the while the solution has to be out now and has to be good enough. i think i became immune to rolling out frameworks when a quick point solution is needed, so now the battle has moved to a finer level – testing as risk management, for instance – in the absence of time i test the stuff that is most likely to contain bugs, and i test coarse-grained user-level functionality first instead of polishing up individual unit tests.

but really, all this “micro focusing” business above is not that bad and is quite manageable on day to day basis. what i am trying to figure out though is how it applies to my career in general.

my problem right now is that after a decade in IT i realize that i have some hands-on skills that would always be in demand, and that there always will be plenty of filler work that will keep me busy and provide some sort of satisfaction (the kind similar to mindless exhaustion you feel after a workout).

i know i tend to become absorbed in day to day stuff, and lose the sight of everything else. NYC is dangerous in this respect – the pace and the energy make you work harder, and one can get fixated on something with a lot more intensity. this is when i find myself performing all sorts of yak shaving feats; is it really what i should be spending my time on?

i think paul graham got it right in his essayNYC has the drive and the ambition, and i feed on it, but i also need to be fully cognizant of its true target. doing something pointless twice as hard isn’t something i am after.

so what is it that i should be doing? so let’s see if i can talk through this.

i always took pride in knowing a great deal about a lot of technical things all the while aspiring to grasp “the bigger picture.” i enjoy being able to build things, drive them to completion, and deliver. i also know that i like dealing with people, solve organizational problems, motivate and build teams.

i really enjoy doing hands-on stuff, and i am pretty good at it; at the same time i’ve seen all too often that most of the technology problems stem from people problems. it pains me to be on the receiving end of business blunders that render my technical efforts useless.

one of the trends in large companies is increasing specialization on many levels of IT. it is inevitable to a degree, but this is precisely where my skills would be least utilized. the image that haunts me is the nine to five drone with atrophied knowledge of everything but the immediate responsibilities of everyday job, unable to survive outside of the large corporation. there are plenty of slots like that – just waiting to be filled.

i want to work in the environment where people around me do have a vision that we all share, and this is what drives our everyday work.

i also like small teams (or small companies) – you get to do a lot of different stuff, you learn much faster, and you feel the impact you make.

so ideally it comes down to focusing on my strengths and consciously building upon them, which means spending less time on everything else.

it sounds quite absolute and final (an also quite fluffy), so perhaps a better approach is to set a goal, timebox it, and focus. if it works – great, and if not – review and start again.

  • current work: spend less time on it; spend less time on filler work; focus on business – actually read the pile of books i have here instead of reading up on tech stuff.
  • spend more time on hobby projects, get back into languages/platforms i abandoned, pick a few projects and actually contribute; build the brand – push for talks at user groups, use real name in forums, blog more on technical topics.

as far as career choices go:

  • i’ve done the enterprise architecture thing for a couple of years before, and despite the raging pundits that the title has accumulated, i think there are great things to be done. you do not have to abandon the technical skills, but you have to realize that your success does not depend on tech anymore. you do end up building and running systems in this role, but they also include people, culture, and organization – not just technology. there is a lot to be said about systems thinking, and there is plenty more reading i need to do. i am also yet to find a good no-bullshit community that thinks along these lines (so far i’ve been really enjoying Stu Charlton’s blog for instance) and people i can work with and learn from…
  • ...which leads me to consulting. what appeals to me here is focus on solving a particular problem (compare that to a less focused role of a regular employee), as well as a great variety of problems, and generally a higher level of expertise expected. you grow and learn so much faster, and ideally this might lead to a product idea, if you see the same problem repeated over and over again. one skill that i know i have is what jerry weinberg calls “jiggling” (see Secrets of Consulting and Are Your Lights On?) – helping people get “unstuck” by asking questions, suggesting tools, practices. often i realize that in many teams although i could do all the work myself, the team would get so much more out of me if i create an environment where people can learn and grow on their own.
  • another option is a product/program owner in a larger company. the biggest selling point is the diverse set of skills required and the sense of ownership. you have a bigger picture, you are responsible for it, and at the same time you need tech, people, and organization to be a success.
  • the refinement of the above is a startup – you build and deliver a product. your impact is tangible, you actually “own” something, and you contribute on many levels, which is a great use for a broad set of skills.
  • and the last option is to get a foot in the door in a larger company as a regular developer (since this is an easy lowest common denominator that is versatile enough and faceless enough) and then try and grow into some sort of a role similar to one of the above. it is terribly inefficient though – most of the energy will be spent on the wrong things.

it does help to write all of this out – having a stake in the ground is a start. let’s see how it goes from here.

reading: team dysfunctions

Posted by anton
on Monday, July 28, 2008

my work-related reading started with programming books and reference materials. then, as i was becoming more aware of things around me, i started reading up on development process, requirements gathering, and all this other “softer” stuff.

when it comes to applying the knowledge, the latter was more tricky – perhaps because it was not just up to me when and where to implement it – other people had to be involved.

with non-technical books it is all too easy to kick back and follow along as if reading an adventure novel – this stuff is engaging, and one might dream of making bold decisions, only if one were in the position of power – all of it from the safety of one’s couch.

in my case i realized that i had to consciously make a mental effort to move from mere recognition and acknowledgment to tangible steps – what can i do tomorrow, in my particular environment? otherwise it will just sit in the back of my mind, and i will mumble behind peoples’ backs recognizing yet another opportunity missed.

this seth godin’s blog entry really helped to illuminate this problem for me – the ideas in a book are just a short bullet list, the rest is persuading the reader to act. so i will follow his advice and pick a book from my recent reading to see if i can get something tangible out of it:

five dysfunctions of a team – is a light read, just a few simple points presented first as a novel, then discussed one by one. but then after reading it, as it was fresh in my mind, i gradually noticed how nicely they applied to the environment around me.

true to its title (admittedly catchy), the book goes over five qualities that are necessary for creating an effective team; they build upon each other, so i’ll pick the first three, since they are the foundation for the rest:


in the team-building context trust is knowing that all the team members have team priorities first in their agenda. it is not being afraid of showing ones’ vulnerabilities, knowing that others won’t take advantage of that. it is knowing that your peers’ intentions are good, and there is no reason to be protective or careful around the group.

trust makes delegation possible – which allows the team to scale and be more effective, as work gets distributed around with everyone aware of individual strengths and weaknesses within the team. the opposite of that is everyone working in their little cubbyhole and reporting up.

finally, trust makes risk taking possible.

i think i consciously made an effort a few years ago to make sure i say, “i do not know” more – this simple acknowledgment goes a long way towards removing barriers within the team. it makes offering help and asking for help possible (which is good telltale sign in itself).

another conscious effort was to apologize more – it works towards defusing the tension and focusing on the problem. obviously, one has to be somewhat self-aware for that to work, and luckily i had a misfortune of witnessing some monstrous examples of personal communication deficiencies, so i have learned from others’ mistakes as well as my own.

team identity

in school we are encouraged to focus on individual goals, so it takes a conscious effort to change that habit for the good of the team, and team identity is one of the powerful aids. one has to consciously build it up – starting from the name of the team, clear statement of short-term and long-term goals, the vision that provides perspective when you are saddled with everyday tasks, acknowledging successes and being proud of them, sharing the problems and treating them as team’s responsibility. there are plenty of smaller things – everything from eating lunches together to casual chit-chat.

secrets and politics within the team kill trust, so my personal resolution is to be more open – have no reservations about telling others what i am working on and why. i noticed that i do hold back sometimes, not sure of others’ intent, and this is definitely a problem.

i also need to give more benefit of the doubt before arriving to conclusions regarding others’ motivations, i think sometimes i am too eager to assume ill intent, and this obviously inhibits trust.


this is the next step, it might come naturally as a result of working together, but it helps to acknowledge and strive for it consciously.

the good thing is that large companies invest heavily in HR review processes. the sad thing is that for the bad manager these twice a year reviews make the situation even worse, since they come across as stilted corny HR drone-induced formalities, so anything that resembles them (like actual good feedback) is squashed even further. as for the good manager, they do not need these, since they do it on regular basis anyway.

so my personal resolution is to give more feedback to my peers (which i think i am getting better at – noticing individual achievements, taking the time to stop by and comment on something casually, etc), but also giving feedback to my management, which i am not that good at.

i think i also need to get better at offering help – taking into account the personalities of others and trying to tailor my offer to that.


productive conflict is essential. if it is avoided, important issues would not get resolved, which will be even worse in the long run. so one must recognize its importance and embrace it, at the same time remembering that it should not be personal.

needless to say, without trust productive conflict is impossible.

i think this is where i could use a lot of work. at some point i became all too aware of others’, so i tend to come across as non-confrontational more and more. i often tend to avoid conflict in the misguided attempt of maintaining everyone’s comfort.

another problem is “picking your fights” – there are always plenty of problems, and one cannot tend to them all. so you either spend your time on all of them and accomplish nothing, or give up and let it all slide.

here’s a common scenario i am guilty of – something is wrong, something is not working, i try a few times to fix it, but it is not my responsibility, although it hurts me as much as the others. so i grumble half-heartedly around the people responsible, but never challenge them openly.

a natural reaction is to ignore it, but that leads to the “broken windows” syndrome (see pragmatic programmer), which, once it gains momentum within the team, is hard to reverse.

it also reinforces the silos – this is my own perch, i tend to it, and others’ should not stick their heads in. ideally, a problem will be out in the open, the whole team would regard it as their problem.

so instead of creating a permanent state of team guilt, perhaps these issues could be put out in the open and prioritized, so that at least these mistakes won’t be made again.

i also primarily worked in the teams where i knew that we could always solve problems ourselves, there was no need to reach out to “higher authority.” it turns out that in large organizations it is sometimes necessary to ask for arbitrage from above to get stuff done. although it pains me to do this, since it fundamentally goes against what i think a leader should be doing, i have to acknowledge the reality and focus on the problem that needs to be solved.


ideally i want and environment where my teammates hold each other responsible for the high standard of work they produce as a team. if someone goofs up, others should be able to step in and challenge them.

here’s an example. given a multitude of assorted projects with various infrastructure problems, one is tempted to create an architectural police of sorts that goes through the checklist – proper logs are written and rolled, monitoring in place, DR in place, etc. while this could be a valid first step in some situations, in a perfect world the team itself will know what these standards are (perhaps since they are wikified) and their personal pride and identity as a team makes them follow these standards and make sure other teammates follow them as well.

it comes natural in a healthy teams, but in dysfunctional teams its absence is painfully obvious: everyone does just the bare minimum to get by, and only certain people in complete isolation try to achieve their own high standards.

peer pressure is a powerful thing – poor performers feel the pressure to improve; it promotes respect, as opposed to resentment between team members with different standards.

of course it builds on the previous principles – it is impossible without trust to give feedback, it is impossible to challenge people with fear of conflict.

so my personal takeaway, going back to fear of conflict, is to challenge people and speak up; i should collect and promote best practices; i should be doing more presentations and knowledge sharing.

it is a gradual process, and with the absence of slack this grass-roots movement is very hard, so at some point there needs to be some management support.

it also helps to hold project retrospectives, because if we lack self-awareness and succumb to “broken windows”, we will make the same mistakes over and over again and take it as a norm. i am guilty of not pushing for retrospectives as much as i could. perhaps as a start i can informally round up a few teammates and go through a few exercises suggested by the “agile retrospectives” book.

why am i so adamant on this being a peer effort? leaders should not be the ones creating accountability, in fact it can be counterproductive – the team will delegate the responsibility to the leader and as a result either become even more passive, or worse, turn against it, seeing it as unnecessarily imposed upon them.

there is a lot more practical stuff in the book, and skimming through it again makes me realize that i’ve missed quite a few tips, but let’s see if i can get some of these practical things done first.

daddy, bring the mojo back

Posted by anton
on Sunday, February 24, 2008

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.

performance optimization: combating the evil

Posted by anton
on Monday, December 31, 2007

face the enemy

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

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 environment2).

rule #1: don’t do it

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

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!


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.

1 donald knuth paraphrasing hoare

2 with apologies to m. a. jackson

3 with apologies to w. a. wulf

contributing to projects in the enterprise

Posted by anton
on Sunday, November 25, 2007

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.


Posted by anton
on Thursday, November 15, 2007

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)

looks matter

Posted by anton
on Wednesday, November 14, 2007

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).

interviewing the interviewer

Posted by anton
on Friday, September 14, 2007

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).


  • 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


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 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?)


  • 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.

first time

Posted by anton
on Sunday, September 02, 2007

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


Posted by anton
on Friday, August 17, 2007

from (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 (, for instance), because it is more personal – our home, not a communal place.

hiring technical people

Posted by anton
on Monday, August 06, 2007

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.

we are looking for (interview guidelines)

Posted by anton
on Friday, June 29, 2007

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