Printers

Know Your Limitations of Expertise


Let’s face it: programmers are not experts on every subject IT related out there. While many programmers are great techies, there really is no substitute for hands on experience. Unfortunately, too many developers think that because they can program, and might play around with some non-programming tech stuff at home, and read a lot of Web sites, that they are experts in a lot of subjects that they really are not. And I will be the first to admit that I have been guilty as charged in the past, and still on occasion to the present day.

You know that user we all hate? The one who knows just enough to try to muddle through something, but not enough to do it right? You know, the guy who figured out the chmod command, and then ran chmod -R 000 /* in an effort to “tighten up security

About

Justin James is the Lead Architect for Conigent.

33 comments
rclark
rclark

For the most part, I like to read your posts. This time, not so much. I don't know where this split between Network Admins and the Development Staff is coming from but it is unfortunate. It may be a result of the outsourcing going on. It may be non-native english speakers operating in an english atmosphere, where their native intellegence is not apparent because it is constrained by a limited non-native vocabulary. It may even be a result of a changing netscape. But mostly, I think it is human nature, "I'm better than you because I know xyz." Guess what? Xyz is just the tail end of the alphabet, and is only going to be important until the next new gizmo is released by whoever has the next bright idea. I'm sure there are programmers out there that are guilty of shortcutting policies and procedures intended to protect networks. Been there, done that, lived to tell the tale. I'm also sure that Network Admins and DBA guru's are highly valuable when doing critical load balancing, high volume SQL optimizations, or protecting against injection attacks and viral uploads. But for most projects, for most applications, for most web apps, they just are not that important. Most of the time the network is an enabler. The basic truth to both of those areas are that a newby can operate in their realms without too much trouble. The industry even sells networks in a box and Access will generate your sql statements for you. Will the results be as efficient as what a specialist can produce? Absolutely not. Can they get into trouble because they don't understand the risks and tradeoff's that specialists do? Absolutely. But for most applications, they'll do fine. And the real issue is not one of to be or not to be, it is simple cash. Why would I pay for a DBA when it doesn't make any differnce to the app? Why spend additional time designing protocols that are already in place with hardware, software, and human beings and only slows things down without providing value? Yes, good design is good design, but most apps do not have a decade half life so the ROI has to be now. CPU cycles are cheap. Disk drives are cheap. Programmers, DBA's, Network Admins, and Help Desk Guru's are not. By developing a circled wagon mentality, we leave a soft center that can be exploited. By developing inefficient sql statements, we risk slow response times or server crashes under heavy traffic loads. But if we imbed the firewall in our processes, they have to change when the firewall changes. If we spend a 100K to get efficient sql statements, that 100K won't be available for new development. Sometimes it's critical. Sometimes it's worth it. Sometimes it's not. That is what management means. So the basic message is, put your money where it will do the most good. If it is critical, go for it. If it's not, live with the tradeoffs, pick up the pieces and get on with it.

Litehouse
Litehouse

While I agree it's good to know your current limitations, I disagree with some of the attitude of your post Justin. You pretty much imply that programmers should stay in their box and out of your way when it comes to technical issues. I'm a programmer, but I started out as a techie and DO have quite a lot of hands on experience. I didn't move to programming because I couldn't cut it, I moved to programming because I wanted more challenges. When I say it's good to know your limitations, I mean, so that you know where you need some work. Now with that comes the caveat that you NOT pose as an expert where you have those limitations, and seek guidance in those areas instead. When I'm asked for assistance (many times from the current batch of techies) in an area I'm not very familiar with or don't know the answer to, I say so. I then generally do a little research if I have time and let them know the results. Yes, I have tech privlidges, but no I don't abuse them.

Mark Miller
Mark Miller

I've experienced this when working on apps. that someone else wrote. Every time it's happened I've hoped and prayed that the original developer can be contacted so I can pick their brain. Sometimes I haven't been so lucky. The most recent event was a little more than a year ago. I was brought on to modify an MFC app. After having made the modifications some bugs showed up. I fixed most of them, but one was still bothering them. A seemingly unrelated problem was occurring. The app. was supposed to create a report calculated from inputs to the app. They were coming out incorrectly. I hadn't worked on the report generation code at all. The people I talked to told me what the result was supposed to be, and it was way off. They also showed me the result it used to produce. Interestingly it was incorrect as well, but it was not as far off as what the new version produced. I fell into a trap: "So they're both wrong?" I asked. Apparently so. This made me wonder if this was a deeper, legacy bug. One that had been lurking for a long time. This was diagnostic behavior I had carried over from my days as a full-time employee. I had some extra time to burn investigating problems back then. Anytime I investigated a problem it was an opportunity to deepen my knowledge of the application, which used to always be a good thing. At that point in time though I was working as a contractor. I looked at the area where the calculations were supposed to occur. The app. was using formulas that I didn't understand. So I asked one of the guys if he knew anything. He attempted to instruct me on how everything was supposed to be calculated. What he was showing me didn't match with the method that was being used inside the app. This got me worried. I figured there must be SOMEBODY within the company who knows these formulas. I asked the person I talked to repeatedly about this, but it didn't clarify things, though I'm sure he did his best to provide answers. Finally in another meeting they suggested I take a look at the source code of an old app. they used to use. It turned out it used many of the same formulas that the new version used. This confirmed that the formulas as they were were correct. Secondly, by collaborating with one of their managers, we figured out that he had entered one of the inputs wrong. This narrowed the problem down to my code. It turned out I had neglected to change some code properly, and unbeknownst to me it was causing a formula to miscalculate its results. The code had bad encapsulation to boot. It took me a few weeks to figure this out. It was a process of elimination. It turned out that no one who worked at the company knew about these formulas anymore. The original developers of the old and new apps. were gone. It was up to me to do the elimination, though their tutoring of me in the basic idea of how things were supposed to work helped some. I learned a few lessons. One of them I used to know from working on my own code: Just because a problem appears to be coming from one area of code doesn't mean it isn't being caused by code somewhere else. Usually I clued into this possibility because the app. would crash in an area I hadn't worked on. This didn't happen. Instead it was a logic error that just produced incorrect results. And I was thrown off by the fact that the output of the old version did not match expected test results. Another is, work on the simplest solution first. Instead of being ambitious and trying to solve two problems, it would've been better if I had just focused on trying to make the app. work like it used to, looking in my code for problems, even though the results they were getting were wrong with the old version. That would've directed me to where the problem really was, and it's likely we would've figured out why they were getting incorrect results from the inputs later.

Justin James
Justin James

Where do you draw the line and say, "I need to talk to someone more expert in this subject?" J.Ja

Justin James
Justin James

"I'm also sure that Network Admins and DBA guru's are highly valuable when doing critical load balancing, high volume SQL optimizations, or protecting against injection attacks and viral uploads." This is actually the exact situation that I was dealing with when I wrote this post. I think we are in agreement, I just came out really harshly on one side of the topic, while rather ignoring the other side, which you stated pretty darn well. Right now, on the app that I am dealing with, there are a lot of technical woes. I am not sure if it is a lack of expertise in general in the development team, a lack of resources, or what. But for what we pay in licensing fees for the application servers on a per-socket basis, it is worth $10k or even $50k, I think, to have a real pro or two reviewing and rewriting the code to get us some efficiency. You are 100% right: hardware *is* cheap. But the licensing, administration, cooling, power, support, and management fees for each piece of hardware are NOT cheap. Google, for example, spends more on powering and cooling its data centers than the cost of the equipment itself, if I recall properly. Once an app gets to a certain scale, there is this magic point where the development costs become a minor cost in the ROI calculation. The #1 problem I see is that it is hard to balance the cost of development (particularly on a new project that is not yet proved to be marketable/sellable and is not generating revenue yet), the the long term need for it to make efficient use of hardware resources. J.Ja

Tony Hopkinson
Tony Hopkinson

Business constraints tend to be far narrower than technical ones. These guys weren't inventing a new wheel, they were driving their SUV down a crowded sidewalk.

Justin James
Justin James

I really understand where you are coming from. My current role is to not manage people, but to manage particular technical aspects of a project. What that means for me is that I am relying on the various team supervisors and my own judgement as to who is best suited for a particular task. I really cannot afford to throw the dice on someone who is not the best fit for the task, there is too much at stake. Which means that I am really not in a position to help give someone experience. That being said, I agree with your point, in that not knowing something shows where you need work. If I find myself frequently confused by one particular angle of a project, that means that when I get home, I need to read and *practice* those ideas. Are we doing a lot of regex work? Then I'll write a screen scraper or something to learn regex's better. Are we doing database work and my SQL is a bit shoddy? I'll get cracking on a small database project. Etc. Etc. Etc. Indeed, employers find it attractive that I do so much with tech at home, because it means that I have a lot of experience. More importantly to them, that experience is not going to come at their expense. That is why we see job ads loadedc with acronyms under "skills", as opposed to "looking for a really smart person who can learn anything, but does not necessarily know anything already." Sad, but true. Once you hit mid career in IT, unless you specialised in something on the wane, it really becomes easy to find jobs. But it takes a while to claw your way to mid career, which is one reason why IT has a high weed out rate from the freshman year of college through about 5 - 10 years into the career. J.Ja

Litehouse
Litehouse

What does this have to do with the topic at hand?

jslarochelle
jslarochelle

In a crisis situation (a bug in the field or a when a critical strategic decision is involved) I will quickly search for help or point to someone else to do the job if I think some aspect of the software I'm not an expert in is involved. In the context of new development it will be more like a poker game I suppose. I will tend to "bluf" if I think I can learn the techniques involved and do the job. To do this in a productive way I will also have to try guessing what "cards" the project manager or other people involved have in their hands. Is the project already in trouble because of schedule contraint, etc... Of course once I'm assigned to do a job I will not hesitate to ask questions to other programmers if am having difficulties with some aspect of the domain or technique involved. I think intellectual honesty is one of the best asset of a programmer. However, because I don't want to get stuck in a technological niche or problem domain area I have to be able to guess when it is appropriate for me to take chances and sell myself as someone who can learn new techniques and explore new business domain. JS

w2ktechman
w2ktechman

set firecrackers into the computer take the computer or printer to the roof and watch a free fall for impact testing bring in a shotgun to make sure that the system is really dead start pulling parts out of it and throwing them onto the floor and then jumping on them placing them as targets on the range (firing range that is) pulled all of my hair out that day, and the day isnt over yet kick the machine to try to jumpstart it use a stun gun to try to recessitate it make smoke and sparks, possibly a small fire pour water over the unit cause its hot and thirsty So there, plenty of good reasons for when I need to go for help it doesnt happen too often, but sometimes, just sometimes I would like to try one of these approaches. It seems like it would be satisfying (except for pulling ALL of my hair out) as I have already lost too much.

bg6638
bg6638

You say Let?s face it: programmers are not experts on every subject IT related out there. I positively agree with that, however I've encountered employer after employer where they want people who have 20+ certs(MCSE, CCNP, CCDP, CCIE, RHCE and others), 5+ years of experience with VB 6.0/.NET, C#, C++, AJAX, Java, PHP, Oracle, SQL Server, MySQL, Project Management, etc., etc., etc., i.e. a walking expert on everything to do with IT! It would be great if someone could enlighten these people that nobody can possibly be an "expert" in every facet of IT!

customsunlimited
customsunlimited

I have people I hire to give me the answers I need. I nor they, will ever have all the answers, but I do expect the honesty to say so, and that they have the expertese to know how to find them, QUICKLY!

karsten.breivik
karsten.breivik

Justin - you said you just installed IPCop. It is a nice firewall. I've used it alongside Smoothwall which is its ancestor and a few of the other Linux based firewalls. However, I tried out pfSense a few months ago and I absolutely love it. It is based on m0n0wall - FreeBSD based and in another division completely than IPCop. Both much more advanced and perhaps even simpler to install. It has better traffic shaping, more powerful IP settings, remote admin surveillance, a lot more graphs, live vector based traffic graphs, better logs, can use several extra NICs, supports VLAN for more advanced networking. I have never looked back :-) Just remember to check out the settings at the bottom of the page in general settings to get the DMZ/Opt1 to work correctly.

Jaqui
Jaqui

wherever I happen to get stuck and can't resolve the issue through my own research. I am always willing to ask for help, since it's an opportunity to increase my skills just as much as reading on the subject is.

Tony Hopkinson
Tony Hopkinson

I'm very bad at asking for help. I enjoy the finding out more than the find.

Mark Miller
Mark Miller

The topic was know your limitations of expertise. I pointed out that the section of code that calculated the report used formulas I didn't understand. I thought initially that the bug was in these formulas. I thought I could understand them one way or another. In my experience I had almost always been able to solve problems if given enough time. This was one of those cases where I couldn't come to understand the formulas. I was able to recognize them as patterns that could be matched against formulas used in old code. That was the ONLY way I was able to confirm that the formulas were correct. But as to their significance, what they really meant, I hadn't the foggiest. I eventually realized that no one at the company knew what they meant either. It was only when we both (me and my contacts at the customer site) found out that one of the inputs we were testing with was wrong, that I finally recognized that the fault was in my own code. What I was discussing was learning a strategy for a "when in doubt" situation. I attempted to dive into an area for which I was not competent. A different strategy, avoiding this area of non-competence as much as possible, would've been the better route.

Justin James
Justin James

I know *exactly* what you mean. HR departments are rediculous for that, esp. in the IT field. Can you imagine a job ad for a "scientist with 30 years combined experience in organic chemistry, electrical engineering, quantum physics, string theory, cancer medication research, and ceramic engineering"? Neither can I. Yet they do it with IT. J.Ja

Justin James
Justin James

... but BSD tends to be much more picky about hardware, and the device that I installed it on is fairly obscure, although the components seem to be fairly run-of-the-mill. That being said, my needs are fairly simple, I just wanted something a few steps above the Linksys router, and not too hard to use. The biggest trouble I had with IPCop was figuring out that CopFilter's SMTP proxy did not work with port forwarding on port 25 turned on, even though it was clealy stated in the admin page. ;) J.Ja

DanLM
DanLM

Ever hear that expression? That's how I describe myself. Meaning, I do read a lot. I try to put into action things I have learned in test environments. But, I do know my limitations. Ie: I know nothing about send mail, and will readily admit to that. Networking, yea... ok, nic card gets inserted here and I plug it in. If you remember a previous post I had, it dealt with the purchase of hardware server research. Their is a primary area where I really do not feel comfortable from a business environment. But, because I do have what I consider basic knowledge(more then most where I work). I was asked to do that. Yea, I definitely know my limitations. Both in coding and other area's. Dan

Justin James
Justin James

... not everyone has the breadth of knowledge that I know you do (not being sarcastic, either). Where you know your limits to be, many people do not know that they have a limit at all. For examole, I *know* that I have no business debating the merits of particular Linux distros, because I have not used any of them, other than here & there. But take the guy who also has never used Linux, but sure reads about it a lot, and all of a sudden he sounds good enough to dictate a Solaris server setup... J.Ja

Justin James
Justin James

... but somethimes (too often), my "figured out" is not nearly as good as someone else's "already knew". :) Not just in terms of time, but frequently in terms of quality... like all of the times while I was halfway through writing my own code library for a task, only to discover that it already existed, buried deep in the documentation. That's one thing I like about Visual Studio, I can putter through the IntelliSense and find stuff that I might never discover. :) J.Ja

Mark Miller
Mark Miller

Hi Justin. Since I was working as a contractor though it wasn't the best strategy. I ended up wasting a lot of time, going way over our estimate. I ended up having to eat this portion of the project. I agree, if I were a full-time employee I would've had the luxury of beating my head against the wall, but in this case I didn't. [i]I have seen similar situations, being asked to code something to replace a legacy system so old, no one actually knows exactly what rules govern the legaxy system. People have a vague conept of what happens inside, but at the end of the day, it is trial-and-error, shoot from the hip, and firing "tracer rounds" at the problem (or "probing by coding") just to see how it actually works.[/i] I came in towards the tail end of a project several years ago that was kind of like what you describe. The project was way beyond the original schedule, and way beyond the original budget (I think the final figure was about 2x the original estimate. Talk about eating the loss! It was a fixed-bid project :( ). As these things often tend to go, I don't learn the full scope of the project until months later. Usually I started out just looking at the project in small pieces, fixing bugs, making minor enhancements, etc. Later I learned that the genesis of the project was to take a Windows 3.1 app. and rewrite it for 32-bit Windows in C++/MFC. The kicker was all the original dev. team was given was the production version of the original 16-bit app.--no source code--, and a descriptive 1-page write-up on how the search engine was supposed to work. I'm not being sarcastic. It really was descriptive for the amount of space it took up, though it wasn't complete. Other than that the spec. basically said, "Make the 32-bit version work like the 16-bit app., along with requested enhancements." I took one look at that and blanched. Oh--my--god! I don't know how the original team did it, except they must've spent some time literally reverse-engineering app. There were some issues that I fixed, based purely on conversations with the customer liason who didn't have a head for software projects. His last position was as a salesman. He and my project manager did NOT get along. Anyway, these issues were of the type you discussed earlier, something about dealing with user-created databases. Fortunately the business rules encoded in the database followed a convention that while not ideal was good enough that a simple parser could reasonably deal with them. We even had trouble deploying the app. It was supposed to communicate over the customer's network, and the customer refused to give us a network topology. My guess is for security reasons. We were literally flying blind on that front, and the liason blamed us whenever the deployment screwed up, like we were supposed to know better. Sheesh! I was amazed the project got as far as it did. It was close to completion by the time I was done with it.

Justin James
Justin James

Mark - I always enjot reading your posts, esp. the ones longer than my original! I have seen similar situations, being asked to code something to replace a legacy system so old, no one actually knows exactly what rules govern the legaxy system. People have a vague conept of what happens inside, but at the end of the day, it is trial-and-error, shoot from the hip, and firing "tracer rounds" at the problem (or "probing by coding") just to see how it actually works. That's how I learned regex so well, beating my head against the problem, until I because an exoert at it. Now I can write PCRE with a top level of proficiency (it really is a DSL unto itself, when you think about it, esp. since the syntax uses so many characters that are reserved in its original language [Perl]), but it took a lot of time getting to that point. I have worked on a lot of reports, where the only way to test if the new report was "right" was to run it side-by-side with the original until it was consistently in agreement, because the business folks did not know their own rules. J.Ja

Justin James
Justin James

... that the HR folks ask the manager, "what technologies will this person work with, and how well do they need to know it?" and then convert "expert" and "proficient" and so forth into "years of experience." Every programmers knows that this is an invalid methodology. Someone could work intensely with a particular language for 6 months, and be ten times more expert than someone who has been writing "shake 'n bake" code in the same language for 6 years. Likewise, if my "2 years Linux experience" is in using RedHat with KDE to cruise Web sites, it is worth a lot less than someone else's 3 months setting up a bunch of special purpose (email, Web, firewall, storage, etc.) servers in a build out. The ads have got to be a bit more specific regarding *what* someone was doing, and talk about particular methods, not broad technologies. J.Ja

Mark Miller
Mark Miller

They keep doing it. I've seen employers doing this since 2002 when the IT job market suddenly got very tight. I've heard various theories about it. I don't know which to believe. Some used to say they did it to limit resumes because HR was getting swamped with hundreds or a thousand resumes for 1 position. I don't find this believable with conditions as they are now. Others have said that companies do this to game the visa system. If there's a requirement that a company must try to hire a U.S. citizen for a position first, they make the requirements exhorbitantly high so that hardly anyone qualifies. Then they can say, "Hey, we tried to hire someone local, but no one qualifies." That gives them the excuse to bring in a foreign worker on a visa. Both scenarios sound plausible to me, depending on market conditions, but I agree it seems strange. As I understand it the IT job market has gotten better since 3 years ago. I know I've gotten headhunting calls since then. I get them every few weeks sometimes. That wouldn't be happening if the job market was bad. The other possibility is maybe they're looking for and finding people with these qualifications. I don't think we're ever going to know. What I love are the ads looking for 3 years of .Net 2.0 experience, even though the final release has been out for a little more than a year. I heard one employer say, "Well there are developers who have worked with the betas," which is probably true, but really, how many are there? Not that many I suspect. Personally I think that's kind of a cop out. Employers have been doing this since I was a young 'un. When I was in college in the early 1990s a college professor told me about this. I think it has to do with HR equating "years of experience" with seniority in a position. They don't know what's going on in the industry either, so they have no idea a technology has only been around for a year. I've sometimes wondered whether the people who get those positions lied on their resumes. What they're asking for is so unreasonable anyway. I've never done it. If anyone asked my advice I'd say, "Try to find a way around HR." Make a connection inside the company, if you can, and send your resume direct to them.

Justin James
Justin James

... businesses frequently cannot affords mistakes. On my current project, the privacy of tens of thousands of people is at stake, and there is the potential to spread a virus or a worm to hundreds of thousands of people. Not to mention the millions of dollars at stake. In a nutshell, it means that we have to run in 100% risk management mode. Indeed, my last position was like that too. While there is still room for taking a chance on a less knowledgable person researching or feeling their way through a problem, we have to be extremely careful. What I am saying, is that with someone who is not as knowledgable or experienced in something, I have to establish a level of trust in their ability to crafter a solution on their own. Give them less important or risky items outside their knowledge domain, especially ones where a more experienced person can take a look at it, and we're fine. But for a mission critical piece, no way. J.Ja

Litehouse
Litehouse

What a great post Jaqui! I totally agree.

DanLM
DanLM

By recognizing your limit's though does not stop you from attempting something new. At least in my case. It just provides me with guidelines on how I feel I should accomplish the task. Ie, take my time and figure it out. And now my limitations have changed, and on goes the cycle. Example: 2 area's that I have to do something that I am uncomfortable with. Sendmail and bind. Why, cause I'm going to make some money on this from a personal endeavor. So I'll just learn it/figure it out and get it done. For what I am trying to do, I need both. Hell, the fact that this is going to be a side business is something that I've never done.. I never felt comfortable with the idea of starting a business. I think a followup thought to this is.... If you think you are limited in your knowledge in a specific area, don't be afraid to go for it. If you fail because you never fully grasped everything involved, don't let that stop you from trying it again. Lessons learned is a part of removing limitations Dan

Jaqui
Jaqui

that the only person that really knows what you can and cannot accomplish is you. I had that driven home even before I started school. [ like the summer before my very first day of school or a year before that ] I watched the gymastics for the summer Olympics and decided I wanted to learn how to do a flip. Went out into the back yard the next morning and spent hours working on it. landed flat on my back hundreds of times then finally made it. did several front and back flips until I knew I could do them at will and went running up to my mom while she was cooking lunch. Told her that I could do flips, and asked her to watch. her reply: "No you can't, it takes years of hard work" and she wouldn't even watch. since I know I had done several I was quite insulted, then realised that only I know what I can do. I also realised that by just doing it without getting input from anyone else I avoided any negative input that could inhibit me. That day was the last day I ever let any preconceptions from anyone determine my abilities, I have consistently done whatever I needed to to accomplish the job, without reguard for any specialised knowledge or skills needed for it. We do all have limits, but we can limit ourselves by not trying to increase skills / knowledge, or by our attitude. That is the wrong thing to do, since by learning something new, or accomplishing something new, we improve our self esteem.

Tony Hopkinson
Tony Hopkinson

Two of my biggest weaknesses were, one more try at solving a problem and one more go at improving the solution. Well, that said they are weaknesses in a business environment, because you aren't given the time for it.

Ian Thurston
Ian Thurston

I work as a jack-of-all-trades consultant, AKA "Assistant General Manager of the Universe." My clients are often willing to pay for me to learn on-the-task. I still love the rush of solving a problem that seemed impossible (especially when the newsgroups say "Ya can't git there from here.") That means a lot of head-against-the-wall rhythms. And when it comes beating my head against the gyprock, one of my colleagues gave me some valuable advice years ago. If you're starting to wear a hole in the wall over the same issue, set yourself a limit of a half hour. When time's up, call for expert help, and cover the sound of swallowing your pride by clearing your throat. As one of my other buds put it, "Life is so much better after you give up all hope."

Justin James
Justin James

... it is only five minutes. When I work for larger companies, I try to quickly suss out who the really smart or knowledgable or connected folks are, and go to them with questions if I cannot figure something out. Smoke breaks are a great tool for this. If I know that Joe has in depth knowledge on an obscure topic, even though it is not his primary job responsibility, I will have saved myself hours of frustration if it coms up by knowing that Joe probably knows the answer. J.Ja

CharlieSpencer
CharlieSpencer

It feels so damn good when I quit. I have a problem recognizing the break-even point between the knowledge gained working out the problem by myself and the time saved by seeking assistance from someone who knows how to fix it.