As a programmer how broad does your knowledge have to be ?

Question

I am pretty focused on software, I try to keep up with all the new stuff that comes out and like a lot of other people I have a hard (but fun :) ) time keeping up. Still I believe you need to keep up so you know the best possible solutions for many problems.

Lately I have gotten more and more into discussions on levels I just don't know enough. Discussions on Infrastructure, do I use a failover here or do I cluster my sql servers over there. Discussions on Security about ADFS, Threat modeling and counter measures Discussions on Business processes and how they are modeled and how the software is aligned with the business goals.

So the question is : Where do you draw the line ? Is there stuff we really don't need to know anything about ? Or can we identify areas and a level in those areas we need to try to reach.

Answer 1

The real question is, what do you want to be responsible for, and what do you feel comfortable being responsible for? If you accept responsibility for the design of a system, you should feel confident that you can either make the appropriate decisions or bring an experienced person in to direct those portions you're not comfortable with. It's fine to push your comfort zone, but you should determine how hard you are willing to push.

You should ALWAYS feel comfortable saying, "I don't know". From there it is up to you to decide to accept responsibility to learn more or be accountable for more parts of a system.

As a caveat to your below comment, there is a difference between project management and programming. It seems clear that you are coming from an experience of getting burned by a bad project manager (or no project manager), and are now looking to find ways to CYA basically by learning more so you don't get stuck in a position where you deploy a broken product.

My advice.. let this one go.. Chalk it up to bad project management, BUT do this in the future: Play the I don't understand card until you really do understand what the product/project you are supposed to build is. Don't assume you understand what requirements are. This basically forces one of 2 things to happen; either a person gets assigned to be project manager who can actually answer your incessant questions about things you don't understand and is responsible for the overall project success, or a clear project plan emerges from your detailed questions that you WRITE DOWN the answers to(document) and you effectively become the project manager.

This goes back to the question of if you want to accept the additional responsibility of being project manager. Maybe you don't. But if you do, it's pretty simple to think of the questions to ask. Just say, "what happens next", then "how do I do that" to every single thing you are supposed to accomplish for the project. If your answer is at any point "I'm not sure" (which is a good thing to identify), then you have to follow up with "what happens if that fails". Here's a scenario.

Your last project was introduced by your boss: build a website to sell our widgets. You say, website, no problem. What happens next? (after it is built). the answer should be pretty easy, step 1 build the website, step 2 deploy the website step 3 ??? step 4 profit!!! (sorry, had to). But then you ask, "how do I deploy the website" ? Are you sure or not sure(see above)? then you get to the almighty "what if it fails?", and you go from there. At that point you have to go back and ask the question again "do I want to be responsible for deploying the website".

That is planning, and good planning ensures good outcomes. It sounds like you already know what bad planning is, and are looking to avoid it a second time. I need to stop now, so good luck!

Answer 2

There is always a lot to learn and the answer to Your question depends on what You want:

If You want to be a specialist, then focus on one topic and all techniques that are "neighbours" of it.

If You want Your projects done and You have specialists at hand, You should learn everything to understand Your customer and translate it into the language of Your specialists.

Answer 3

You can't know everything and trying to learn everything will finally burn you out. What I recommend is to find out what your co-workers or team member are best at. Use them when you run into problems you don't know the answer to. Work with the stuff you find most interesting. If you do, you probably will be really good at it. My advice it simple: Know where to find good information, either it's in books or its inside the head of the people you work with, and extract this information whenever you need it. I believe that the best software is build by people who knows how to work in a team and fulfill each other.

Answer 4

Always take the opportunity to learn something new, and always do things the harder way.

Answer 5

Are you part of team? How large of a team? On a large team you can specialize fairly narrowly. On a small team, or an individual developer then you don't have that luxury. Even if a member of a large team, the more you know, the more you are capable of, the more valuable you are. Personally I like learning new subjects and I prefer to be a generalist, but that it me and what I am comfortable with.

Answer 6

You need breadth of a lot of things at a high level and depth on a few key, currently relevant technologies.

Answer 7

In one of the comments you left with another responder you said that you are a Software Architect.

If that's true, then you absolutely must know and understand the ins and outs of infrastructure. This means OS, Network, DB. Otherwise the title is a misnomer.

So, taking it from the Architect perspective language specific things like generics become meaningless. An Architects focus is on bigger picture items.

Answer 8

If you find it interesting, and get excited about the concepts - study it. If you have to know it for your job/career - study it.

Answer 9

Breadth is proportional to Depth or Quantity is proportional to Quality.

An architect should have a greater breadth of knowledge caring more about how the entire system is going to work, and which things hook together, but not about how each piece is implemented. Whereas a C# expert in Asp.Net is going to know exactly how to implement the hook that ties the database to the browser through business logic.

Acquiring knowledge should be based on three things:

1. Interests - What are you interested in, if there is enough passion you should already be learning and gaining knowledge in that area. Make sure you create, and not just learn. It is much more fulfilling to complete a project based on your interest than learn about how somebody else did it. If you have a variety of interests then your knowledge will be broader. If you really only enjoy games (and making them), then you'll become an expert in just that one area.

2. Work - What does your job require of you? Learn those features or technologies that will help you do your job better, more efficiently, and make it more interesting.

3. Career - Is there a different career path, or promotional path that you would like to pursue. Take classes, get a degree, or just learn and practice in that area.

You'll need to balance each of these according to your goals.

Answer 10

Simple answer is "It depends." Here are a few factors that influence where the line may be drawn:

1) Company hierarchy. If there is a group responsible for networking, then they should be the ones to handle network issues. Similarly, if there is a database problem, you may be able to hand it over to some administrators where you work. Course if there are only 3 IT guys and they handle anything that comes up, then it may be each guy has a really diverse skill set.

2) Software breakdown. I've worked at places where there was a clear separation of who worked on what parts of the overall architecture. Thus, being a front-end developer, I got to handle the tier with HTML, Javascript and a little server-side code that talked to an object model which I had no control over other than to request new features or for someone to look at some code as there is a bug in it.

3) Team strengths. Are there others on your team that seem to be the expert on something that you don't want to study inside out? If so, this is again where I could see a line being drawn.

4) Know your own strengths. There may be some parts of IT that appeal to you which you can specialize in to some extent for another way to know which areas to go diving into. Are you more of a DB or eye candy person? Do you have specific experiences with some software that a company may want from you, e.g. some SAP certification or work with a particular CRM software?

Last but not least, there will be what one could call, "Domain Knowledge," which varies from company to company which are various terms it uses for things such as project code names, names for the products it sells, nicknames for various people, etc. How are orders, customers, and other entities the company does business with organized? This can be a learning itself if the developers have to dig into how things run to solve the issue.

Answer 11

The answer is simple. Learn everything. Joking aside, i have to answer your question with another answer. How good you really want to be ? IF you want to be the best you don't to draw lines and things like that you just work+learn, learn+work every day of your life.

The better programmer you want to become the more you need to know.