Home > .NET, Management, OOAD, Patterns, software engineering, Technologies > The wrong attitude of learning on the job

The wrong attitude of learning on the job

June 6th, 2007

I can’t tell you enough about how much surprised I was when some developers applying for senior .NET development position, when being interviewed by me, could not answer very fundamental questions about a specific technology or programming language as well as were not aware of any trends in the field. What I found out was that usually this had something to do with their attitude towards “learning on the job”.

Some of them even told me that they consider questions like “what are the differences between value type and reference type”, “when should you use interface instead of abstract class”, “compare ‘protected’ and ‘internal’ accessibility levels” and so on (I listed some others here) are theoretical and not useful for the job. They went on saying that they never found themselves think about these when doing their jobs and yet they could still get their jobs done and even got promoted to the senior position. Some even went as far as saying that things like design patterns were impractical for real-world projects. Reasons like such went on.

Most of these folks have many years of experience in software development, but they have the experience of doing the same things over and over again. Besides, instead of trying explore many technological possibilities to pick the most suitable way of accomplishing things, they only learn enough to get the job done. These developers are confused between getting the software built and getting the software built the right way and yet they think they are perfect examples of those who learn on the job the right way – which can’t be more far from the truth.

The sign of this type is that their knowledge and skills are no broader than what they have applied in their past projects and no deeper than what barely necessary to finish the tasks assigned (and they usually refer to anything beyond that as “theoretical” or “impractical”). For example, they know how to code a data access layer to map relational data to the object model, but they have never heard about NHibernate, iBATIS.NET or even the term ORM tools; they know how to implement ASP.NET pages, but having no knowledge about the page life cycle; they know how to code or use a collection class, but they have never learned to use generics; they design a new system based on the way they designed previous systems instead of based on project-specific trade-offs and design principles; they use C# 2.0 without knowing about anonymous delegate and iterator; if you ask them to apply logging to an existing system, they will open one thousand something methods to add the Console.WriteLine() (not even logger.Info(), less AOP) to each of them; and if their bosses don’t ask them to write unit test (chances that the bosses will never do so), they do not know what on earth NUnit is. The list goes on…

Obvious is it to see, software built by these developers usually are work of hacks (negative hacks) and under-perform in terms of reliability, maintainability, extensibility, cost-effectiveness and so forth. In fact, because of their lack of breadth and depth in knowledge they can only pick a solution out of their limited number of solution alternatives, and they will need a great deal of time to troubleshoot / debug code when something goes wrong behind the abstractions. But, their learning attitude alone, which often implies a lack of motivation or interest in their career, will already make them look very bad in the hirer’s eyes.

I always hesitate to follow-up with these developers, even just to offer a junior or mid-level position. I don’t care if they have the ability to quickly learn about new things or not, because it is the fact that their multi-year experience shows me that they did not spend the effort to learn how to do things more effectively and chances are that they might continue with that in the future.

  1. June 6th, 2007 at 23:25 | #1

    I totally agree with you on definite benefits of fundamental knowledge you mentioned although they are not fundamental ones in my point of view. I’d refer them to principles. There will be nothing to guarantee that we build healthy software without principles. I don’t say the good software because good software may not be healthy one.

    The article is good warning to those who are on the way of improving their knowledge. This helps readers to identify the best way to go and from this point I believe their job will be easier and better, significantly!!

    However, we shouldn’t be too severe as you said. Majority of knowledge you’ve listed out should be considered as an advantage for candidate rather than a must. Let’s try those questions with those who considered good/senior developers to see how many of them and how many percent of correct answers they will get? It is the fact that they are recognized as good/senior ones by what they have performed. We cannot disclaim that just by those kinds of questions.

  2. June 8th, 2007 at 05:40 | #2

    “Unlike in the investment world, past performance is indicative of future results in the world of software developers. ”

    Wow, I couldn’t disagree more. No, wait, I could after reading -

    “I don’t care if they have the ability to quickly learn about new things or not, because it is the fact that their multi-year experience shows me that they did not spend the effort to learn how to do things more effectively and chances are that they might continue with that in the future.”

    Saying that the ability to “quickly learn about new things” is unimportant in the face of not being a master or expert in a particular coding aspect is so far fetched from how it works in the small team environment it’s scary to think about how organizations led by those types of people continually makes improvements and don’t just stick to “tested and true” coding practices.

    In my position before my current one, I was hired on as a junior developer under 3 developers each with more than 15 years experience. One developer was an ASP guru (he’s even co-authored a book), one was a C developer (she built missile guidance systems in her past life) and the other was a mainframe developer. When our CIO told us to migrate applications off of aging and antiquated software to .Net, the 3 senior developers struggled mightily to “switch gears” and to learn the nuances of yet a new language. Their past performance had ZERO indication in their ability to take our institution to the next level, meet deadlines and complete third party integrations.

    I could give the example of how I needed to know ASP.Net, VB.Net, C#.Net, Crystal, Acctuate, Steema, XSLT, XML, CAML, JavaScript, PHP, C, VBA, Deltek, mySQL, SQL Server, ASP, etc. all just during this 5 day work week and I challenge anyone to come in here and be able to answer, in the most efficient manner possible, how to accomplish all of the programming tasks I had to solve this week in the most efficient way possible without performing due diligent research. This is where, in medium to large teams, you can get away with “specialization”, but smaller teams do not have the resources to specialize IN ADVANCE and must be able to research the best method and implement the method quickly and accurately.

    Your entire approach and why it’s not presented properly can be summed up easily by the following -

    You are saying to not hire programmers who use learning on the job as a crutch and I would agree. However, the ability to learn on the job quickly and keep pace with the ever changing landscape is not only desireable, but necessary to staff successful development teams. You need to be able to differentiate between the two during the candidate’s interview. Ask them what the last programming book was that the read, are they going to get their Masters, are they still studying for certs, what RSS feeds do they read daily. Interviewing is a lot more than running down a list of questions and evaluating responses.

    Sorry to rant, but I do appreciate you stirring up my blood pressure to keep me awake this Friday morning. :)

  3. Eugene
    June 7th, 2007 at 18:25 | #3

    Ok, so I consider myself a developer that you described. I am not going to explain too much why I am not learning a lot of new stuff, I don’t think anyone is interested. But all you said is true — I code ASP.Net without paying attention to the page lifecycle, but I KNOW it will bite my back one of these days. And I do want to be ready when the time comes.

    Hence my question: how do you prepare for those challenges? For example, tell me, Buu, how you gained the core knowledge, or how you, wsw, learned all that.

    Thank you.

  4. stark
    June 7th, 2007 at 18:28 | #4

    who the heck does your screening? how can someone like that even get past the initial interviews? maybe if you improved the HR phone screens, etc. you won’t be wasting so much time with such inferior candidates.

  5. June 7th, 2007 at 19:27 | #5

    I have to somewhat disagree with you wsw. Although we’re on the same page with regards to fundamental knowledge, I have to say that a lack of understanding of some of the specific concepts mention in the article will most likely lead to poor(er) execution.

    I’m not saying that there is an Interface to be developed in every program (although there are usually several patterns whether you define them as such or not). I am saying that understanding that these things exist and what they are for leads to everything from better google searches to (more) reusable code. These are the types of topics that need to be considered when labeling someone a ‘Senior Developer’ as they will most likely be building the libraries others depend on as well as mentoring the more junior members of the team.

    Anyway, not a major disagreement, I’m just leaning a little more towards one side of the fence I guess. Great thought-provoking article!

  6. June 7th, 2007 at 19:43 | #6

    @Eugene. It’s not easy mate; at least not as easy as it used to be. It’s not easy because it’s hard to separate the wheat form the chaff and there are so many technologies piled upon one another that it’s hard to focus your learning.

    My advice for page life-cycle would be to start at the beginning. I deep understanding of the HTTP protocol would be the basement of the house you’d be building.

    For interfaces, patterns you’d have to first have a very good understanding of the root OOP topics. I hesitate to offer this as a suggestion, but learning basic C++ or Java (I personally used Pascal a long time ago) might be a good plan. Both of these languages allow you to get to the fundamentals of OOP without the layers of other technologies sitting on top of them (unless you ask for it).

    Once you have hit problems of multiple inheritance and had a few polymorphism nightmares it’s time to start delving into topics such as interfaces and then patterns. By then you’ll be ‘aha’-ing out loud as you read some of them ;) .

    Good luck, it’s not an easy road, but very rewarding.

  7. June 7th, 2007 at 20:14 | #7

    @Eugene, we cannot learn all, just as must as we could. By knowing that there are some knowledge areas that are more important than others and by knowing that some knowledge can leverage others we can have good choices for our transient lifetime. I started my first design, I didn’t know whether it’s good until I read design principles. When studying a new thing I’ve tried to find it’s principles first. I recognized it was a lot of easier for me to approach. With such thought-provoking article, Buu brought to the reader this attention, I guess.

  8. June 7th, 2007 at 20:44 | #8

    @Mike Mullen: You have provided good comments and examples. In my opinion, who knows basic – will be talent!! I would give a high rate to whose who knows such fundamental knowledge. In reality, I don’t think there is more than 50% senior who live around us can afford to have 100% correct answers. If you rate senior by your grading scale it likely a little bit far from current.

  9. Dave G.
    June 7th, 2007 at 21:59 | #9

    You said:

    “I always hesitate to follow-up with these developers, even just to offer a junior or mid-level position. I don’t care if they have the ability to quickly learn about new things or not, because it is the fact that their multi-year experience shows me that they did not spend the effort to learn how to do things more effectively and chances are that they might continue with that in the future. ”

    I agree completely. Unlike in the investment world, past performance is indicative of future results in the world of software developers. If someone has spent their career learning just enough to get them by, and no more, it’s very likely they’ll continue along that path. And to me, a “junior” developer is someone fresh out of school in their first job, and a mid-level has about a year’s experience. If, after working two years with a particular set of technologies, a person doesn’t qualify as a senior developer, then they’re not going to work for me.

  10. June 7th, 2007 at 22:29 | #10

    The level is really dependent on the specific environment – it’s more easier to get to the senior level in some companies than the other. In my case, a senior level developer must at least have a broad and deep knowledge in the applied areas/domains and be able to mentor other junior developers in technical skills. Obviously the type of developers mentioned in my entry cannot meet those two minimum requirements. But hey, are you saying that you’re working in the environment in which more than 50% of your fellow “senior” developers do not know what design patterns, ORM, xUnit are?

    Actually most of these interviews I referred to in this entry are the phone screening interviews. At my site, both HR and technical manager do phone screening – after passing the HR quick screening, the candidates then talk to the technical managers. Because of that, sometimes I have the feeling that the HR folks are unhappy because I turn down so many applications who have a lot of years of experience in software development (which is usually the only thing that the HR folks can really “measure”, BTW). But I don’t blame them though, sometimes it’s just hard for HR to know that a developer with 10 or so years of experience in software development and a lot of projects under his/her belt is in fact just a junior developer with a lot of ages :-) .

  11. June 7th, 2007 at 23:50 | #11

    I would start with the fundamentals, which can be different dependent on your specific environment. A solid fundamental background will make it easier to pick up new things.

    Assuming that you’re doing .NET web stuffs, I would agree with Mike’s comments. Pick some good books on OO (the Head First book on OOAD can be a good start if the book’s style matches your taste) and read them cover-to-cover. Once you have a good OO skill, things like refactoring, unit testing, patterns (don’t miss the GoF pattern book) etc. are more natural. Next, read some good books on how to become better coders in any kind of technologies/paradigms (Code Complete, The Pragmatic Programmer etc.)

    It’s also nice to learn about HTTP and web server stuffs – you will understand ASP.NET or any kind of web related techs/ideas like Ajax, SOAP/REST web services etc. much deeper and easier. Don’t forget to find a decent book on the programming language(s) you use and on ASP.NET (the ASP.NET book by Jesse Liberty may work) . Finally, check out the book “CLR via C#/VB.NET” to learn about the really involving .NET knowledge.

    I think that’s pretty enough for the fundamentals. You then need to expand your horizon, surfing the web/blogsphere and learning about AOP, Spring.NET, NHibernate, NUnit, LINQ, WCF, Silverlight etc. – no need to learn very deeply about every new cool things, just enough to know when they can be useful or worth a try, and try when you have a chance. (A good fundamental will also help you detect hypes, there are a lot out there, better.) And finally, if you may, learn more languages. The point is, by expanding your horizon you will also expand the depth of your existing skills/knowledge.

    It will take time Eugene. It would take years for a typical person to learn and apply to master the stuffs mentioned above. But then, I think it is fun. Stay curious and good luck!

  12. June 8th, 2007 at 04:49 | #12

    Ironically this article will be read by those who share your opinion and care about their craft and will no doubt be missed by those developers you describe!

    Such is life eh.

  13. evilkayak
    June 8th, 2007 at 08:37 | #13

    Maybe these ‘seniors’ are not really seniors and are coming with resumes exaggerating their work experience?

  14. Lee
    June 8th, 2007 at 09:24 | #14

    I completely agree. IMO developers have to understand that they will never see a 40 hour work week. Any developer that wants to have a wide skillset within their programming domain will almost certainly have to spend a good amount of their own time reading and doing projects on their own.

    Most programming jobs will have a developer doing the same thing or similiar tasks everyday. Large software projects especially ones that are full of bugs will not progress fast enough for a developer to get to exercise various facets of their skills.

  15. June 8th, 2007 at 11:44 | #15

    As a comparative old-timer in the coding world (35, have a wife and kids, house, etc.) I can tell you that sometimes the best practices come after the fact and at times subversively.

    If you work in a software-product related startup or marketing driven deadlines, you may very well not have the institutional buy-in for the upfront time associated with Test Driven Design, extensive modeling, etc. Implementing patterns and alt-coding toolsets can be seen as academic exercises when CFOs are interested in hour by hour metrics on ecommerce sites. Its nice that a lot of companies are now starting to buy into doing the right thing, but the overworked, unrealistic deadline startup software shop will always be the beginning of the next stolid, reasonable mid sized business.

    That said, the benefits of learning and implementing best practices, frameworks, toolsets, and constantly sharpening the saw do of course have a great ROI for your company, you just wont be able to sell them on it. I think its reasonable to keep in mind that a lot of developers working in these environments will be hard pressed to learn or do these things, and may be actively punished for doing so. To discount their cleverness because they have not had the opportunity to formalize the patterns they have probably discovered on their own can be a hiring mistake.

    That said for you as the the startup dev to accomplish your goals, sometimes you need to be the lone wolf. Sometimes you have to fake some deadlines to enable you to furtively read the books, and spend good chunks of personal time in order to refactor some giant switch statement into a factory.

    Sometimes you have to operate in “better to ask forgiveness than permission” mode.

    Once you’ve done this for a while though you’ll find yourself becoming a leader whether you intended to or not. The company will come around when your tactics have proven ROI, you just need to give them a taste of it first. You’ll find your job satisfaction skyrocketing, as well as the realization that you are gaining career (not just job) security.

  16. Ray
    June 8th, 2007 at 11:58 | #16

    I have to somewhat disagree with the post. Sometimes the very thing that makes people “Senior” has nothing to do with any technology. This is a fact that is often time lost on Junior people, which only understand the details of the language, ide, framework, etc.

    I will agree that a job applicant should have knowledge of concepts like ORM, NHibernate, NUnit, LINQ, WCF, Silverlight etc.. As stated in the post, you can learn the details on the job.

    I am much more interested in interviewing someone that has worked in multiple languages and frameworks. When .NET Framework 5 comes along and makes all this stuff obsolete, then that person can adapt and overcome. Flexibility and adaptability are the real keys.

    At the end of the day, you need to be solving business problems and for some people it doesn’t make a difference if you used MyGeneration or CodeSmith.

  17. Steve
    June 8th, 2007 at 12:30 | #17

    I always wince whenever I see senior or junior attached to a title in programming. Especially for HR folks hiring, the only thing they have to work with is years of experience and buzzwords on a resume. It’s strange that if I have 8 years of experience in the field coding maybe 15-20 hours a week, I’m somehow “better” than the kid next door who codes 10 hours a day 6 days a week for 2 years. We’re dead even in coding experience, I’m just older and have seen more ideas die. It’s stupid.

  18. June 8th, 2007 at 13:16 | #18

    All-too-familiar story. I don’t know how many times I’ve started an interview with, “What’s the difference between an object and a class?” and the answers have been so wrong it’s not even funny. What’s worse is this usually comes from those who say on their resume that they have lots of .NET experience.

    Nothing surprises me in interviews anymore :)

  19. Ubercoder
    June 8th, 2007 at 13:42 | #19

    I agree with you 100%.

    Something that you never mentioned is the type of projects us developers are working on.

    Everything comes down to what I call the “cookie cutter” methodology of dealing with development.

    You’ve been asked to make some cookies. They give you the materials to make them.

    So you start by thinking: “I need to make cookies”

    You have two choices:
    1) Create a cookie cutter. Use all my skills to make one that is adjustable, can make cookies in different shares, is not sticky, etc”.
    2) Get a regular cup and use this as a cookie cutter.

    The first solution needs skills, decision making but most important TIME.
    The second is a hack, but is FAST.

    So, the question here is: What kind of project you working on?

    Most companies that create software for their internal use, they ask developers to create software not the right way but the fast way. Most of the times the created software is used for couple months or at all.


  20. meijin
    June 8th, 2007 at 17:17 | #20

    “Do not judge, and you will not be judged.”

    –when being interviewed by me, could not answer very fundamental questions about a specific technology

    You have no clue what a fundamental question is.

    –Some even went as far as saying that things like design patterns were impractical for real-world projects.

    Once you understand them you should throw away all design patterns. Or as some Master said: “He must so to speak throw away the ladder, after he has climbed up on it.”

    –These developers are confused between getting the software built and getting the software built the right way

    The problem of getting the software built in the right way is undecidable.

    –they do not know what on earth NUnit is

    You misspelled JUnit. Did you ever wonder how hard was programming before JUnit was invented? Amazing that the old school hackers got some things done properly.

    –reliability, maintainability, extensibility, cost-effectiveness and so forth

    On short, bullshit. Unless you have an MBA and a political agenda you are not suppose to use these words.

    – always hesitate to follow-up with these developers, even just to offer a junior or mid-level position.

    You do them a favor as for sure is no fun or intellectual satisfaction to work with such an inflexible project manager.

    Stop blogging on things you don’t understand yet and get a life.

  21. Bobbie The Programmer
    June 8th, 2007 at 18:22 | #21

    Often this attitude is justified by “why should I take my spare time to make more money for my employer.”

    Unless it’s studying some in-house framework, learning more will help one in getting the next job, and the one after that.

    In Perl, which I know a zillion times more about than .NET, I see many “senior” people who:

    Don’t know how to pass parameters by reference

    Can’t write their own classes

    Don’t know even the basic uses of the map and grep functions

    These are three items that a long weekend with the basic books on Perl will teach you. It’s disappointing to watch. I’m not a world-class Perl guru but I am reading all the time and learning new things every week.

  22. June 8th, 2007 at 19:25 | #22

    Is it possible you misunderstood these senior developers point? Maybe its not that they are anti-intellectual, but they just dont think in your intellectual terms.

    For example I have of course read and own the gang of 4 design patterns book. I have it next to my book oft consulted STL book, and my new book on TR1 libraries –

    I use design patterns everyday. I just dont *think* in terms of design patters in an intellectual sense. Even the gang of 4 would tell you themselves, the purpose of the book was to codify *existing* practices, and provide a common _nomenclature_ for professionals to talk about them.

    When Im coding, I think “I need a single class that has behaviour X”, I dont think I need “The Singleton Pattern(tm) (pg. xx 2001) blahblah”. And if you asked on the phone to contrast The Decorator pattern with The Visitor pattern, and when you would use them, I would hang up on you for being an insufferable pedant who confuses book knowledge with demonstrated ability.

    I can tell you Ive had some interviews like that myself, where its nothing but book-learning and logic puzzles, and I can tell you afterwards Im thoroughly disgusted by the display of self-superiority for knowing the answers to their own questions, and wishing that the employer gets exactly the kind of employee theyre looking for — as punishment.

  23. Khurshid
    June 9th, 2007 at 01:46 | #23

    Such people who have not bothered to learn more than the minimum will be like that forever. These guys just do not have the willingness to learn new things else they would have done that already.

    They may be senior in terms of the quantity(man hours) of the work they have done and the projects delivered, not necessarily in terms of their knowledge.

  24. Jacob
    June 9th, 2007 at 03:20 | #24

    Of course if you’re using Microsoft as your main platform you’re going to have a lot of dumbed down coders. Microsoft actually touts that idiots can use their development products. Hey, but I’m simply a student.

    I actually have to take a Visual BASIC course as a requirement eventually (and I will undoubtedly have to fulfill it as an independent study as I’m way beyond its curriculum), but I absolutely hate the thought of building an application that only runs in a Windows environment; I really do.

    meijin says:
    –reliability, maintainability, extensibility, cost-effectiveness and so forth

    On short, bullshit. Unless you have an MBA and a political agenda you are not suppose to use these words.

    I say:
    Please do not make me take the time documenting your uncommented legacy code for the sole purpose of being able to more efficiently modify it. If I write code, then I’m usually going to want someone to use it. If I want someone to use it, it has to be easy to use. If it’s not reliable, maintainable, extensible and blahblahblah, not many people would even take the time unless it were an extreme situation, in which case I wouldn’t feel like screwing them over.

    I really hope you’re not one of those guys that flip-flops between character arrays and strings ten times in a stack of function calls just to use a function you made that applies to strings because you’re too lazy to implement it for character arrays. I’ll give you the benefit of the doubt.

    I’d like to mention, I don’t necessarily know a lot about specific technologies, but I would take a weekend to learn about such things simply because of the fact that I enjoy making my own ridiculous expectations easier to attain.

  25. June 9th, 2007 at 08:12 | #25

    I do not agree with you on most points. While it is good to have fundamental knowledge of the technology/language, being as specific as you have mentioned in your blog isn’t definitely appealing to my taste of discerning between a good programmer and an average programmer! Unfortunately this is the way that big corporations work and no wonder productivity is so low. Compare this with startups where a veritable student fresh off college could become an expert in just two years on the job! Show me one student who really even gives a fig for all the theoretical gobbledygook of which he would hardly use, what a hundredth, on the job?

    The one place I definitely concur is constantly updating oneself with the latest innovations in one’s respective field of expertise (in the very least!) so that one does not go on re-inventing the proverbial wheel with every project that one undertakes.

  26. Stranded
    June 9th, 2007 at 12:26 | #26

    meijin, congratulations. You have just demonstrated exactly the behaviour pattern that Buu criticizes. Say, you came across an unknown term (in this case, NUnit). And, instead of asking yourself: “Is it possible that this NUnit really exists? Is it possible that I don’t know something that other people do and I may benefit from finding it out? Shall I invest a few minutes of my time to google it and find out what it is, just to broaden my horizons?” you rush ahead and declare something totally unknown to you either unnecessary or an error or both. Lamentable.

  27. June 9th, 2007 at 15:15 | #27

    Thank you Stranded for your clever comment, you surely understand irony. Let me explain it to you:

    BEGIN_IRONY You misspelled JUnit END_IRONY. Did you ever wonder how hard was programming before JUnit was invented? Amazing that the old school hackers got some things done properly.

    Before NUnit was JUnit so pun intended (ignoring Smalltalk’s SUnit).

    As a matter of fact, I wrote more (C#) NUnit tests that you could imagine. However I wouldn’t blame somebody that never heard about these tools as there is nothing special about them. You can always trade wisdom for knowledge but not the other way around.

    And a short remark: you cannot expect to win a debate if you use ad hominem arguments. Let me know if I have to explain to you what ad hominem argument is.

  28. June 11th, 2007 at 02:35 | #28

    It looks like a lot of the developers you mentioned went straight from their colleges to software companies, without any work experience. That’s acceptable, of course, as nobody is born experienced.

    What is unacceptable is that the “boss” does not have a clue about programming nor new technologies and methodologies, and does not encourage his developers to pursue ew knowledge. It’s more of a management problem than a problem with developers.

    Entry-level programmers should always have a mentor, who would show them see of the tricks he learned, and would teach them how to find references and communities in the net. Well, the reference is not enough, as it seems to be “carved in stone” most of the times. The most valuable resources now are the blogs, as they deal with most recent problems.

    From my own experience, the best programmers are the guys who are self-taught. Sometimes they need some guidance, and they need to be un-taught the mannerisms that they have learned on their own, but they are very eager to learn.

    Once, in one of the interviews I went to, I was asked a simple question: “what blogs do you read?” It’s a perfect question to elicit whether the candidate is passionate about programming and is he up-to-date with the news.

    An important concern has been raised here: experience != mileage. *creating a draft on my WordPress*

  29. June 11th, 2007 at 12:30 | #29

    Thanks a lot for your comments, everyone.

    The ability to learn things quickly is obviously expected. No question about that.

    Good point! I’m not aware of any environment in which the bosses say “boys, you have 40 hours per week, spend 10 to sharpen your skills and the rest to code the apps”.

    @Mike Duncan:
    Good point on how to cope with unsupportive environment, Mike.

    Absolutely. Incompetence does not express in creating bad design, it is also in over-designing the needs.

    Part of adaptability comes from the fact that you possess a good amount of fundamentals and current knowledge because most new things are built on top of existing things. Hide in the mountain for 10 years and come back, then tell me how quickly one can learn .NET 5.0 faster than others :)


    You have no clue what a fundamental question is.

    Not all levels of “fundamental” need to be technology-independent. I don’t see anything wrong in saying “fundamentals of .NET framework” or “fundamentals of web programming” and so on.

    Once you understand them you should throw away all design patterns

    It’s different between an expert designer who does not need to think about patterns when designing and a person who has bad design skills and yet has no interest in learning about patterns (a good way to learn about design, I would say). Fortunately, it’s pretty easy to tell between the two.

    they do not know what on earth NUnit is
    You misspelled JUnit…

    Isn’t it more relevant to talk with .NET developers about NUnit than JUnit?

    The problem of getting the software built in the right way is undecidable.

    “Right” is context-dependent, but it’s not undecidable to a competent team.

    Unless you have an MBA and a political agenda you are not suppose to use these words.

    Sorry for being dump, but I don’t see why people need an MBA to talk about things like reliability, maintainability… can you explain?

    Excuse me for not responding to the last few of your comments.

    I agree with many of your points. I don’t ask people to compare Visitor and Decorator (or Factory and Abstract Factory) – by the book knowledge about patterns is of little interest to me. Typically, I ask the candidates to describe how they designed or would design a specific problem, and if it turns out to be a bad design, I provide hint whether they know some patterns/principles to apply for the circumstances. Another question I often use after the candidate has confirmed that s/he knows about pattern is “which pattern do you prefer the most, and why?”.

    You raised some valid points about the issues regarding fresh graduates. But I talk about “senior developers” in my post.


    It looks like a lot of the developers you mentioned went straight from their colleges to software companies, without any work experience

    I wouldn’t write this blog entry if this is the case. In fact, some do have a lot of experience. I agree with you that the problem of not pursuing further knowledge also has to do with management – in many circumstances, good managers should encourage and create a learning environment for their team.

    I’m looking forward to your blog entry :) .

  30. anon e mouse
    June 12th, 2007 at 06:24 | #30

    While I wasn’t hired a a senior C#/.Net dev, I was definitely in this position before.

    These people are probably just desperate to get a job of some type, or to leave their current situation for greener pastures.

    When I took up ASP.Net/C#, I learned about all kinds of crazy stuff having to do with the language/framework. This is going to sound snooty but after checking out Rails, I tried to find the same kind of thing in ASP.Net. Studied Castle Project, NHibernate, code generation, all kinds of stuff to try and achieve the same kind of RoR zen.

    When I didn’t find it, and had to muddle through so much bloat / etc. to deal with things the ASP.Net/C# way, I pretty much gave up and starded seeking a RoR gig where I could then learn that “on the job” to some extent. (they were aware of this, though)

    ps. if I get desperate enough again, I’ll start padding my resume & applying to all kinds of different jobs where I don’t have 100% perfect experience. If you’re smart/savvy/ a quick-learner enough, sometimes learning on the job really can fly, barely. =)

  31. choy
    June 13th, 2007 at 00:25 | #31

    Although I agree with most of what you’re saying, I can’t help but sense a certain amount of elitism here. Sometimes I question whether I myself am studying this stuff to be more effective (wise), because it’s cool (childish), or to increase my elite quotient (very adult). I love the wisdom of the sages as much as the next geeky coder. really i do.

    But just because the candidate can’t do our elitespeak or bookspeak doesn’t mean they aren’t capable coders. And I’m sure there are plenty of bad coders who can talk the elitist talk but can’t quite walk the supercoder walk.

    In my travels, which includes a long stint at a design patterns study group, I have met some talented coders who can’t tell you the difference between an “object” and a “class.”

    But they still have this uncanny knack of doing the right thing. Their gut tells them when a responsibility is misplaced. “It just feels wrong” to them. They do rigorous unit testing (implying they design units) – may not be automated – but rigorous. Remarkably productive and efficient. A whirlwind to watch in action. These guys are running at 60 mph and I’m trying to convince them to crawl with NUnit and CruiseControl and what not.

    Oh, and they ask great questions too. questions like “why should i know the difference between an object and a class?” “is it possible this man page is wrong?” Sure, you won’t be able to explain things to them and they’ll have some wierd magical way of explaining things to you but the communication gap should be more than compensated by the raw talent.

    In summary, I think you should consider again some of those guys you’ve passed up on. Although scholarly diction probably correlates with talent, absence does not necessarily indicate a lack of talent. Personally I’ve learned a lot from these plebeian coders ;-)

  32. Bill Malkin
    June 13th, 2007 at 06:07 | #32

    Good points! I hate it when people “learn on the job” as I have to maintain their crappy code! They’re too damn lazy and arrogant to do industry certifications or professional development of any kind and their code is absolutely disgusting. “Learning on the job” is a euphemism for leaving behind a great big heap of stinking rubbish. Not that it bothers me of course.

  33. July 19th, 2007 at 20:44 | #33

    Hi Buu, I’m J2EE software engineer.

    I don’t agree with you saying that they are advanced knowledge. In my point of view, they are basic knowledge as well as every good developer must know. If someone can’t answer these question, they just be a junior developer, not be a senior developer as they said.

    Maybe, in the .Net world, M$ supports a lot of thing and they wouldn’t care these fundamental thing to make a good software. In our world, that’s basic knowledge which every Java developer needs to know! I’m honest.

  34. October 1st, 2007 at 06:11 | #34

    I have always made an effort to learn a language comprehensively. I have also had an interest in design principles, because I’ve seen the results of badly designed software.

    I have a couple easy questions that I think will tell you a lot about a candidate up front: Have they ever written a class from scratch? Have they ever derived a class from another one by themselves?

    A lot of Windows developers probably have not, but have instead just used the facilities that VS.Net gives them. It creates their classes for them and many of their methods. The tool basically directs their design choices. They feel this false sense that they don’t have to think about it.

    In my own experience, even though I know about abstract classes, the last time I used one was in C++. I’ve used my own interfaces in .Net, but rarely. To tell you the truth I don’t see how you could use .Net without having a rudimentary understanding of interfaces. The framework uses them extensively. It’s difficult to use .Net classes in combination with each other without this knowledge.

    I think what you’re also seeing is people are still so used to .Net 1.x. Some of the blame I think lies with where most developers look for information. They typically consult MSDN docs most of the time, which never used to give examples about creating object models to use with applications. There was barely any documentation (none from Microsoft) about how to use ASP.Net with business objects, and how to databind to objects. Without that I can understand how it would be difficult for developers to see the advantages of ORM. This has changed with .Net 2.0, but it seems a lot of developers have not gotten with the program.

    If they genuinely cared about development issues they would’ve learned this stuff without Microsoft docs. and searched for a way to implement it, rather than just saying “I don’t care about it since Microsoft didn’t talk about it”.

    I agree with you that there are some things that are not merely “theoretical”, but would tend to make life easier, like generics and ORM. Any senior developer would be a fool not to learn about them, because they can save a significant amount of development time (ORM does have its pitfalls though, from what I hear).

  35. October 2nd, 2007 at 13:10 | #35

    Thanks for the thorough comment, Mark. I largely agree with your observation about Windows-app developers. I also agree that there are not a lot of MS docs discussing about building good software design while focusing mostly on how to use the MS tools (so that the tools can do the “design”). In fact, talking about focus, if you compare the certifications in the Java (like CJP, CJD) and .NET (like MCSD.NET) spaces, you will also see the assessment methods/topics areas are way too differently.

    Having said that, I am seeing some changes in the .NET space lately in which people pay much more attention to things which are not MS-built. Another good thing is that MS starts seeing the value of stuffs like Ruby, ORM and implementing such products on top of the .NET platform.

  36. December 25th, 2009 at 01:04 | #36

    I like choy’s comment.

    However, standing on Buu Nguyen’s perspective, the points made by choy and meijin and a few others are all good but irrelevant. He was making interviews on the phone. The applicant Bob had X years of experience doing Y in his CV, yet he doesn’t know deeply enough about Y. Bob should not be hired. That’s all.

    Suppose Bob is instead a smart Unix hacker in his CV, Buu Nguyen would probably ask different questions (assuming he still wants Bob, which he should).

    Hiring is extremely hard. Without actualy doing interviews, you would think that you can tell the good people from the bad ones just by talking to them, seeing if they are smart or not. But that just doesn’t work out in practice. I have been there.

Comments are closed.