Skip to main content

Are You and Expert?

If you have been in the software development field for any length of time you've had to wear many different types of hats.  There the DB, API creation, Web design, Web code/JS, remoting / streaming, UI, Requirements, Architect, Help system, Error handling, Customer service and a zillion other types of hats that are required for a typical project in our field.

I enjoy all of these different roles that I've needed to perform, however it does not make me an expert in them all.  I'm good in most of them, expert even in a number of them, but I know where my strength and weakness lay.  I must still learn from others.

In my youth I wanted to be an expert in everything.  Learn something new then I would quickly become an expert.  Well, not so fast, wanting and being are not the same and I needed to learn that.

I first needed to become an expert at myself and that took time.  I needed to understand what I knew, what I did not know and when it's helpful for me to provide comments and opportunity to learn.

I have found (and this is just my opinion) youth wants to be involved.  It's fair, when we are young the world is our oyster and our own self knowledge may be overstated but our enthusiasm is not.  Later in a career the perspective may be reversed.  Our knowledge may be greater but we now know how much more there is too learn and, this is very important, when we should provide input on what we do know.

I'll give some examples that you may have seen before :

- If you are in a meeting where everyone has strong viewpoints and wants (demands?) to be heard, you may want to take a look around the room.  Is everyone in the room an expert on the topic?  What is the age group represented in the room?  Is the discussion calm or anxious?  I've been in so many meetings of this type early in my career that it's a wonder how anything got decided.

- If you are in a meeting where there is a calm flow of thoughts and ideas between a few of the participants with a smattering of "stupid" questions that re-focus or re-base the topic at hand then you may be meeting nirvana.  The primary discussion is between the topic experts with the "stupid" questions coming from the non-topic experts working to learn more.  The "stupid" questions are not stupid at all, but are an active part of the questioning that is used to attach the current topic thread to a foundation where others can provide valid input.  It's a learning process in action and a path to becoming an expert (after your 10,000 hours, more or less).

Asking what I call "stupid" questions can seem like exposing your lack of knowledge, and it does, but it also exposes the current topic thread of not being based on reality or facts.  It can add a breather to the flow to provide a quick re-evaluation of the issue and validation that it's on the correct path.  You may be surprised at the path change that can occur after the question.

The becoming an expert in yourself is for 1) knowing what you are and are not an expert in and 2) when you can provide valuable input in a discussion and learn from others.  Without this knowledge you risk thinking you are an expert when you are not.

The risk of thinking you are an expert can be detrimental to yourself, your career and to projects that you are involved with.  You can fool yourself into believing almost anything, but you can not fool others involved in the project or your customers.


Comments

Popular posts from this blog

There is no "Right" way.

It's not that your way is not the right way, it's that everyone has their own right way.  So which is the right way?  Is there a right way? Software development is full of discussions that revolve about the "right" way of doing something. The terms used in discussing software design, tools and implementation are so undefined as to make them meaningless.  Code is not designed and written in a vacuum, it's designed by real people in real companies, each with their own constraints and issues.  Code that may look like a hack could have been the result of an employee dragged out of bed at 2am by a company shirt that only cared that they they did not lose their personal client the next morning.  Everything must be looked at in context.  A project written to "Best Practices" may never be finished before development funding dries up.   Goals, vision, constraints and thoughts should be somewhat aligned for project to be successful (or at least enjoyable ...

3rd Try is a Charm

I've been trying to draw / paint these barns for a couple of years but never felt or got them right.  This time I think they turned out right. So What went wrong before and what's right now with this drawing?  This time, the light was right.  It's coming from the upper right and the shadows just looked right.  The other thing is the corn field on the left had to "be in season", otherwise it's just a plowed field.  I had taken other photos from different angles but they never felt right.  This angle has the road, power lines, corn field, etc. all leading to the right.  The shadows on the lower right helps fill in that corner (don't forget about the corners!).  The last part is trying to draw (ink paint maybe) the trees in the background.  Not so easy when they are kind of a blob is green shades. So yeah, it's composition that is king.  Many times I just don't see it until the drawing / painting is finished and when it's right it feels goo...

So THIS is My Style?

 If I play around long enough my style will appear.  I'm guessing that this is kind of it.  I'll keep working on other techniques in watercolor but for now this appears to be my style. I do like it and others appear (to my face) to also like this.  Not every one of my paintings is a success.  About 1/3 so far, but when they do I am rather pleased that anything good comes out of it at all. I do love color.  Color is happy and outdoors is full of color, be it the west or back east with the greens.  Color color color. Also doing some painting on hot press paper and see how that goes. Later......