Below are a few general observations independent of any
specific technical debate:
a) Developers love to passionately debate and compare
languages, frameworks, APIs, and tools. This is true in every programming
community (.NET, Java, PHP, C++, Ruby, Python, etc). I think you can view
these types of religious technical debates in two ways:
They are sometimes annoying and often a waste of time.
They are often a sign of a healthy and active community
(since passion means people care deeply on both sides of a debate, and is far
better than apathy).
Personally I think both points are true.
b) There is never only “one right way” to develop something.
As an opening interview question I sometimes ask people to sort an array of
numbers in the most efficient way they can. Most people don’t do well
with it. This is usually not because they don’t know sort algorithms, but
rather because they never think to ask the scenarios and requirements behind it
– which is critical to understanding the most efficient way to do it. How
big is the sequence of numbers? How random is the typical number sequence (is
it sometimes already mostly sorted, how big is the spread of numbers, are the
numbers all unique, do duplicates cluster together)? How parallel is the
computer architecture? Can you allocate memory as part of the sort or
must it be constant? Etc. These are important questions to ask because
the most efficient and optimal way to sort an array of numbers depends on
understanding the answers.
Whenever people assert that there is only “one right way” to
a programming problem they are almost always assuming a fixed set of
requirements/scenarios/inputs – which is rarely optimal for every scenario or
every developer. And to state the obvious - most problems in programming
are far more complex than sorting an array of numbers.
c) Great developers using bad tools/frameworks can make
great apps. Bad developers using great tools/frameworks can make bad apps. Be
very careful about making broad assumptions (good or bad) about the quality of
the app you are building based on the tools/frameworks used.
d) Developers (good and bad) can grow stronger by stretching
themselves and learning new ideas and approaches. Even if they ultimately
don’t use something new directly, the act of learning it can sharpen them in
positive ways.
e) Change is constant in the technology industry.
Change can be scary. Whether you get overwhelmed by change, though,
ultimately comes down to whether you let yourself be overwhelmed. Don’t
stress about having to stop and suddenly learn a bunch of new things - rarely
do you have to. The best approach to avoid being overwhelmed is to be
pragmatic, stay reasonably informed about a broad set of things at a high-level
(not just technologies and tools but also methodologies), and have the
confidence to know that if it is important to learn a new technology, then your
existing development skills will mostly transition and help. Syntax and
APIs are rarely the most important thing anyway when it comes to development –
problem solving, customer empathy/engagement, and the ability to stay focused
and disciplined on a project are much more valuable.
f) Some guidance I occasionally give people on my team when
working and communicating with others:
You will rarely win a debate with someone by telling them
that they are stupid - no matter how well intentioned or eloquent your
explanation of their IQ problems might be.
There will always be someone somewhere in the world who is
smarter than you - don’t always assume that they aren’t in the room with you.
People you interact with too often forget the praise you
give them, and too often remember a past insult - so be judicious in
handing them out as they come back to haunt you later.
People can and do change their minds - be open to being
persuaded in a debate, and neither gloat nor hold it against someone else if
they also change their minds.
g) I always find it somewhat ironic when I hear people
complain about programming abstractions not being good. Especially when
these complaints are published via blogs – whose content is displayed using
HTML, is styled with CSS, made interactive with JavaScript, transported over
the wire using HTTP, and implemented on the server with apps written in
higher-level languages, using object oriented garbage collected frameworks,
running on top of either interpreted or JIT-compiled byte code runtimes, and
which ultimately store the blog content and comments in relational databases
ultimately accessed via SQL query strings. All of this running within a
VM on a hosted server – with the OS within the VM partitioning memory across
kernel and user mode process boundaries, scheduling work using threads, raising
device events using signals, and using an abstract storage API fo disk
persistence. It is worth keeping all of that in mind the next time you
are reading a “ORM vs Stored Procedures” or “server controls – good/bad?”
post. The more interesting debates are about what the best abstractions
are for a particular problem.
h) The history of programming debates is one long infinite
loop – with most programming ideas having been solved multiple times
before. And for what it’s worth – many of the problems we debate today
were long ago solved with LISP and Smalltalk. Ironically, despite
pioneering a number of things quite elegantly, these two languages tend not be
used much anymore. Go figure.
