May 16, 2012 at 4:46 pm #161590
On the heels of Josh’s question on if project managers need to be technical comes a controversial posting from Coding Horror imploring people not to learn coding if they are just doing it to learn coding.
Stretching your talents and your knowledge is always a good thing. It doesn’t matter if you programming skills are not good enough to create the next Farmville; the effort alone is well worth the reward. Being more literate in the concepts and tools that make up or modern complex society will make you more appreciative of the work others do and better able to engage in an intelligent conversation with the experts.
It is also a good way to protect yourself from being bamboozled by the experts. A Federal judge in the Google case taught himself Java so that he could better understand the arguments in the case (and came to a key finding). I don’t think the judge wanted to give up his day job (but not bad part-time work on Midnight Coder while he’s waiting for the jury to come to a decision). Rather, it helped him better understand the actual issues of the case and to determine if the experts were actually being truthful in their claims.
Know the limits of your knowledge but do try to expand your knowledge whenever you can.
May 16, 2012 at 7:44 pm #161630
I agree with Jeff! To an extent.
I certainly wouldn’t put down anyone who wanted to learn to code. The example Jeff gives is Mayor Bloomberg learning to code. Unless he’s doing it just for his own fun and personal development, there’s no reason for the Mayor of New York City to learn to code.
Like you pointed out with the example of the judge in the Google case, when you work directly with people who code it’s important for you to know at least the basics.
I’d rather see project managers know the basics of coding and then also focus on software engineering concepts of design, automated unit testing, automated builds, etc. You don’t have to know how to do everything, but I think you should be able to peer review your team’s code and at least have a high-level understanding of what it’s doing and if it’s structured well or not.
May 16, 2012 at 7:45 pm #161628
But I’m a geek by nature too, so I do some php and web development on my own time because I enjoy it.
So you see, I agree with Bill too! 🙂
May 16, 2012 at 8:31 pm #161626
Not sure that the major programming “schools” still offer, but in the Good Ole Days one good take a 3 to 5 day course which provided a rather good overview of the various programming language. As team lead, I remember taking a one week course in Visual Basic, which was more than enough to insure that the staff would NOT be very likely to snow me under with programmers mumbo jumbo when they were having trouble meeting a deadline.
(going to somewhat date myself:)
Because I came up through the ranks of COBOL and FORTRAN programming, the one week course in Visual Basic was more than adequate to meet my needs, however suspect that someone who had never been exposed to programming about the only thing that the course would have done is perhaps taught one a few new “buzz-words”
May 17, 2012 at 1:25 pm #161624
I am a graphic designer and I still don’t enjoy coding. I would rather do the design work and hire a web developer to get the site up and running. Just like any job, some people prefer things over others. For me, coding is not one of them. I do agree that stretching you talents and knowledge is a good thing. I was able to do this when i took some courses on how to code. In today’s world, I agree that it is important to have some basic understanding about coding and just how everything works. Ever ything is directed to websites and knowing the fundamentals of coding can give you an advantage.
May 18, 2012 at 2:35 pm #161622
it definitely helps to have a knowledge of this stuff if you’re working on web-projects. Even as someone in communications some coding experience is helpful. As Henry said, I don’t think a 1 day course will get you much further than buzzwords right now though, unfortunately.
May 18, 2012 at 7:08 pm #161620
That’s a good point Henry. My opinion is that you don’t even need to necessarily know the specific language your team of software engineers is using, but that basis in programming is good. Although, I do think it’s a boon if you take the time to understand the specific technologies your teams are using.
May 18, 2012 at 7:11 pm #161618
Very true Vanessa…I enjoy coding at least to a certain extent (I’m pretty good at coming up with ideas and prototyping them, but I’m a terrible software engineer – it won’t scale and someone who knows what they are doing will have to refactor it).
But you don’t have to be the best at it or even like it; the foundation of knowledge will help you be a better project manager either way.
May 18, 2012 at 7:13 pm #161616
I think the course isn’t a bad route, but there are also tons of great books out there these days and tutorials online like with CodeAcademy.
You can’t just sit back and watch or read though, you have to set up your development environment and start coding up the examples in order to get a true feel for a new language and the concepts involved with software engineering practices.
May 18, 2012 at 10:41 pm #161614
I think learning to code will also help people learn/improve other skills as well, such as paying attention to details (one wrong character can mean a bug that takes hours to find).
May 21, 2012 at 1:53 am #161612
That’s a great point Steve. The concept of unit tests in software engineering can be applied elsewhere as quality checks on many other things you do. In excel sheets for example, it’s always a good idea to have an alternative method of validating totals, etc. – this way you know a typo in a formula or a copy/paste error doesn’t start giving you bogus data.
May 22, 2012 at 2:57 pm #161610
Vanessa, you may not enjoy coding, but you undoubtedly know enough to communicate to a developer what you want, have realistic expectations about what can happen, and understand how the code works when it is delivered. In other words, it helps you work with others and keeps you grounded in realistic expectations.
There are too many managers that don’t understand why we can do project A in a week but project B will take 3 years. It’s all just magic to them. Understanding a little bit about the process and the skill set required to code is a great way to learn to think outside the box.
May 22, 2012 at 8:02 pm #161608
PM’s should definitely learn to code. They’ll understand the inherently complex nature of building and maintaining software and will, therefore, be better PM’s, particularly when it comes stakeholder management (such as setting expectations).
May 23, 2012 at 12:43 pm #161606
Much like PMs need to learn the concepts behind a good project plan (a former boss described the process using Thanksgiving dinner as an example to show how timing, dependencies, and crashing all worked), I think having a PM learn to pseudocode would be useful. Pseudocode is informal, high-level, and uses the structural conventions of a programming language, but is intended for human reading rather than machine reading.
Showing my age now, I learned to write programs in Apple-soft basic in junior high. The first computer teacher I had was our Algebra teacher and he was about two weeks ahead of us in learning the stuff he was teaching (knew there was a good reason they always start with Babbage!). Anyway, as he grasped the why’s and wherefore’s he taught them to us. Writing down what we needed to eventually code was an important step to understand all the why and how. I’m NOT a programmer, but I took Java in college just so I could tell if my coworkers were trying to sell bugs as features when I ran a documentation department. It helped a lot.
May 24, 2012 at 5:37 pm #161604
Thanks Faye! I would love to see a blog post from you describing that Thanksgiving dinner analogy for a project plan, that would be awesome!
May 25, 2012 at 1:47 am #161602
Thanks Josh, you’ve inspired my first GovLoop blog post. Hope you enjoy it:
May 26, 2012 at 3:11 am #161600
I always like the analogy of the NASCAR driver and the crew-chief. At the bare minimum, as a driver you should at least know the basics of what’s going on under the hood. The more you know about the ins-and-outs of coding, the better prepared you are to understand what needs to be done when it comes to designing a website or a system.
That and you won’t be taken for a ride when some slick multi-billion dollar firm wants to sell you a crap system that’ll be overbudget and underwhelming.
May 26, 2012 at 11:12 pm #161598
Misconception #1: IT managers don’t have to be experienced coders because running an IT shop is like driving a car, i.e., you don’t have to know exactly how every piece of auto technology works to drive the car. Actually, IT managers aren’t driving the car. They are building the car for the business side who is driving the car. What can go wrong with having an IT manager who is not a coder? (1) They won’t know what apps to buy, mix, and match for their environment. Easily dazzled by vendors, they buy the wrong apps because they don’t understand how the internals work. Example, buying expensive proprietary content management systems, enterprise architecture, and service desk systems when superior, open source products are free and well supported. Many managers don’t have the capability to rigorously compare proprietary and open source products, or are even aware of specific open source products that are in their field. (2) Non-coder managers buy products that don’t integrate with each other because they think interoperability is a technicality, when actually it is a fundamental principle that must be constantly analyzed with insight into how the details work. Also, non-coders can’t tell when vendors are hiding problems. (3) Not understanding their own in-house potential. Non-coder managers tend to instinctively rush to judgement that contractors are required for every project they don’t understand, and they don’t know that often, their own staff understands critical concepts that they don’t, and is capable of writing better code. These are expensive decisions. (4) Sitting with business side executives, non-coder managers give bad advice and send the organization into unproductive directions. (5) They don’t think of solutions to propose that would otherwise be immediately evident to coder managers. Code savvy managers sitting with executives can often turbo-charge initiatives. (6) There are no better silo builders than non-coder managers. Because they don’t understand data interoperability at the detail level, non-coder managers build silo after silo, drive the organization to data disintegration, leave clients with out-of-date, incomplete, inaccurate data, with tremendous loss in functionality and organizational agility. They retire without insight into the chaos they’ve left behind such expensive legacy systems that can’t talk to each other.
Misconception #2: Coders don’t make good project managers, don’t know how to relate to the business side, and don’t offer solutions in alignment with their needs. The world’s greatest business leaders are BIll Gates, Larry Page, Sergey Brin, Steve Jobs, Mark Zuckerberg, et. al., CEO’s that started out manually writing programming code all day every day. Their products are the most customer centric and successful products ever. What innovative, customer-centered accomplishment has a non-coder provided lately at that level? Coders bring innovation to clients because their work environment continually requires them to take abstract concepts and translate them into real client solutions via programming apps they build. Coders do this five, ten times every day with every feature they write. Non-coders just don’t have their human neural networks undergo such rigorous training. They are too slow to grasp client requirements until the client experiences a problem, but non-coders see the problem as a one-off issue without the enterprise-wide data vision of coders who may recognize a systemic problem for which they can provide an enterprise-wide solution. Coders rigorously remove redundancy from code in a way that gives them extraordinary preparation for removing business process inefficiency in the organization. Data modelers especially have the insight to eliminate redundancy, and improve thousands of business process, apps, data tables, and collaborative human communications systems so that they align with the organization’s mission.
Non-coders cannot build a vision for the future. Non-coders’ only vision is to react to problems, some of which they may have created, that could have been avoided by coders long ago. Coders have a prescient capability to see what clients will need before the clients do, and create a well-designed vision for the organization. Note: The intention is not to imply that non-coder managers are not devoted public servants. They are often the hardest working employees in government. The problem is that they don’t listen to clients, or if they do, they give clients what they want in terms of silo systems that form disintegrated business processes.
Center for Government Interoperability
May 28, 2012 at 1:23 pm #161596
From a blog that I visit
Fortunately, the odds of this technological flight of fancy happening – even in jest – are zero, and for good reason: the mayor of New York City will hopefully spend his time doing the job taxpayers paid him to do instead. According to the Office of the Mayor home page, that means working on absenteeism programs for schools, public transit improvements, the 2013 city budget, and … do I really need to go on?
To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can’t see it.
May 28, 2012 at 4:51 pm #161594
Henry Brown makes a great point that chief executives don’t need to know code. Their primary goal is to define and implement the business mission. IT project managers do need to know how to program, however, please let me suggest an organizational change that allows government to make more sense.
I recommend that the chief enterprise architect should have authority equal to the CEO in order to be able to mandate renitent areas of government to integrate and re-engineer their systems. This new position would solve the problem of slow and unfocused voluntary collaboration between government organizations.
The lack of authority to mandate cross-departmental integration is so determining, that the 911 Commission specifically identified it as one of the factors that weakened U.S. intelligence before the 911 disaster. The 911 Commission states that: Only presidential leadership can develop government-wide concepts and standards. Well-meaning agency officials [..] may only be able to modernize the stovepipes, not replace them. Currently, no one is doing this job.
To ensure that there is cooperation between unwilling organizational units, the chief enterprise architect should have greater authority than all other positions except for the highest executive officer.
Center for Government Interoperability
June 3, 2012 at 7:23 pm #161592
A tad higher than Project manager but would offer that there MIGHT be more than a passing relevance
For the Single Founder Who Can’t Code
A guest blog by Mick Hagen on TechCrunch:
Last summer when I started working on Undrip, I was in a tough spot. I grew up doing web and graphic design so I was a pretty good front-end developer and designer. But I knew nothing about back-end web development – loops, branches dictionaries or functions were all foreign concepts to me. I was a single founder who couldn’t code.
Against the Odds
Every week I get emails from entrepreneurs seeking my advice asking how I did it before, and how I’m doing it now. They find themselves in similar situations in that they’re looking to build a tech startup with little to no technical skills. They’re frustrated by their inability to make forward progress and they usually either give up and fail, or outsource if they have some extra cash (which usually leads to failure).
If you’re a single founder who can’t code, your chances for startup success are near zero. However, there’s still a chance.
And a chance is all you need.
Inspire or Die
There’s only one skill in the world that can make up for your lack of design or dev skills. It’s a skill you have to learn and learn to do well: You must learn to inspire.
Your survival will hinge on your ability to inspire, persuade, and convince makers that they should join you on this adventure. It’s the only chance you have. You know you can’t do this alone. You shouldn’t do this alone. And you won’t do this alone.
You must be logged in to reply to this topic.