What does it take to be a good programmer?
dimitrov2k.wordpress.com
dimitrov2k.wordpress.com
> Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.
That is, code a lot of stuff. And, while doing so, pay attention to how you feel. Sometimes it'll be exhilarating, or you'll be proud of what you done. Other times, you'll be confused, or afraid, or pissed off about how something you wrote earlier is now unmaintainable or hard to make work. This is how you actually learn the insights behind all the dogmas, rules of thumbs, heuristics, good practices, etc. That's how you develop taste - that intuition which will help you write good code.
I was rubbish at maths, but fine at coding.
It's more art than anything.
My current view (it changes every couple of years) is that as a skillset, programming is primarily based on planning and management, most akin to logistical management and orchestration. (we're just lucky our workers are CPUs and resources are memory/bandwidth vs workers you have to individually train, and physical resources that are permanently consumed)
The focus of a programmer's work, and the skills required include:
- domain knowledge and understanding of the work being done
- developing use cases and modelling a solution, often built from well defined and understood 'components' and relationships between them (eg. factory/production, shipping/freight, warehouse/storage, storefront)
- defining processes and procedures to deal with the various states throughout the project's lifecycle
- logic and control flow through these processes including synchronization and validation
In case it's unclear, I _am_ talking about writing code, and not software development in general.
I often think of my data model as a physical system, and its behavior in terms of real world systems. As a simple example, I visualize the function processing a FIFO queue as someone working a specific station in an assembly line factory: their job is to take incoming pieces of a known, expected type and do _something_.
I find this helps me "zoom in and out" mentally, grouping things in context with some understanding of what's going on internally, while still treating it as a "black box". (eg. you can still picture what's going on inside a "factory" when you're looking at it as a whole, with several inputs and the produced output)
That's how I feel as well. Maybe it's a by-product of the software we work on? I work on IT management software and distributed control systems.
When working with control systems, the "science" part typically is in the analysis and testing phases (since we have to come up with models of physical systems). For coding itself, however, it is closer to what you describe.
> I often think of my data model as a physical system, and its behavior in terms of real world systems.
I do this too, especially when programming in Erlang. When building software systems that are modeled as a large number of concurrent, message-passing actors/processes, it readily lends itself to this "physical systems" analogy.
Beginning painters tend to get overly focused on very small details without having a good understanding of how they are bringing the painting as a whole together. They spend too much time on these details, whereas advanced painters are able to move very quickly with faster strokes. It's pretty amazing to see a painting where the strokes don't make sense when you look at them one-by-one, but the overall effect truly reflects something from reality.
I found this to be true also with inexperienced developers. We focus on the latest trends, micro-optimizations, coding styles, and "small" details that are easier to master -- yet we struggle with the bigger picture things like delivering a product quickly.
Kind of like the saying "you can't see the forest for the trees". (You focus on the incidental details, but not the larger purpose)
On a slightly different note, I have several friends who are writers and I have found programming to be very similar to writing a novel. You have to construct a coherent world that "compiles", e.g. the characters interactions are consistent and make sense; each character has a role in the story like a component in a program would have; simplicity and directness tend to be more effective than ornateness; small changes in one part of a dialogue can have cascading changes across the rest of the storyline, much like a refactoring gone wrong.
When I finished grad school in computer
science I went to art school to study
painting. A lot of people seemed
surprised that someone interested in
computers would also be interested in
painting. They seemed to think that
hacking and painting were very different
kinds of work-- that hacking was cold,
precise, and methodical, and that
painting was the frenzied expression of
some primal urge.
Both of these images are wrong. Hacking
and painting have a lot in common. In
fact, of all the different types of
people I've known, hackers and painters
are among the most alike.
What hackers and painters have in common
is that they're both makers. Along with
composers, architects, and writers, what
hackers and painters are trying to do is
make good things. They're not doing
research per se, though if in the course
of trying to make good things they
discover some new technique, so much the
better.
If you're performing, it requires you to tap into some sort of "being in the moment" type of flow that is almost the opposite of deep-programming flow. You have to be aware of the present moment while also interacting with the present moment. Getting "into the zone" while programming, if applied to performing music, is a great way to lose listeners. And if you're performing with others, you'll screw up the ensemble.
If creating/writing, music requires a kind of delving-for-inspiration I almost never have to do while programming. Early 2016 I had to solve a programming problem that didn't fit any previous patterns and wasn't googleable, and I solved that in a kind of lateral-thinking flash of inspiration, so that's somewhat close, but it's still rare compared to normal programming practice... and even then, in programming those flashes are less personal.
Programming is enjoyable in the sense that it's like both solving puzzles/problems and sometimes tending a zen rock garden. You think, you solve, you clean. And to a degree, you express. I don't really think that clears the bar of artistic, but it is manifestation and it is satisfying and it is sometimes personal so that's good too.
The post you replied to seems to be using "art" in the very common sense like the phrase "more art than science" uses it: it's an art in that it requires some type of successful human judgment and subjectivity applied to the needs of a skill. If a fancy calculator can't give an official, right solution (or you don't have this calculator if it exists) somehow that became called an art. Technically, "art" applied to a skill or craft may be the oldest definition of the word. Obviously, these things are gray areas that involve both art and science. See Donald Trump's book "The Art of the Deal" for more info.
Just a question if you see this: Why and how would "delving for inspiration" be an art or artistry? Creativity and inspiration don't seem to be the same thing. Where does the control and art come in when delving for inspiration?
Likewise, in music you have the notes on the page (a computer can even play them). You also have accents and dynamics etc. on the page that require a higher level of subjectivity but instructions/descriptions can be written. Is there another level above that? Is there a part to performing a piece of music that can't be written? Is there a name for the unwritable part?
Your first question: I think delving is more about artistry when it's personal, perhaps when one's own answer would be different than anyone else's. It's easy to be pedantic about this point, but it being personal is on the right track for me.
As for your second, I think part of the artistry of music is intrinsically related to the human element. In other words, let's say there were two recordings of performances or even an original composition. One was composed/performed by a person who felt it as they went, and another was composed/performed by a computer program. Even though it's the same sequence of pitches and waveforms, and impossible to tell the difference from listening alone, I still see the human one as different than the computer one. And if someone says, ah, surprise we told you it was human but it's actually computer-generated, I don't think that makes any kind of deep point, it's more just a dirty trick.
Anyway, the difference between those two recordings, that's the other level above that. I can better respect the human artistry that heard those sounds internally before manifesting them, than the computer program that generated them with AI and statistics.
Absolutely. Excellent point.
Its even more upsetting when you see all these stories of people that only took them 'a year' to start making a good living with it. Typically, they show the most arrogance by asserting that they have what they have because of their merit, when really the company that hired them just couldn't get anyone else that had some specific knowledge in what they were doing, or the job description was wrong, as they always are, so it attracted the wrong people. I don't consider these individuals to be developers of any usefulness outside of their scope of work, because they simply haven't spent time outside of it, so they are not problem solvers, they just look up guides online and make the same stuff everyone else makes.
Being a good developer takes time, it takes a lot of failure, and it takes a continued effort to learn.
So many coders don't do that. It's really hard to just say "Done." and click 'release'.
Then wait for the criticism.
"Good judgement is the result of experience and experience is the result of bad judgement." - Mark Twain
and
"To write a good program takes intelligence, taste, and patience. You are not going to get it right the first time; experiment!" - Bjarne Stroustrup
I think one of the main things that makes a good programmer is someone who cares about the final product. Ironically this doesn't necessarily mean you have to be super good at writing code. I have seen people with what seems basic coding capability very methodically build some really nice software. This is because they are very focused on the "end" not the "means". You see the thoughtfulness of what has been designed in. Sometimes, in the quest of writing "good code" it interferes with writing good software because the emphasis becomes getting good at the means to an end above the end itself.
Not to say improving your coding capability isn't of value, but it's done so you can create even more fantastic things.
I think we see at the other end of the spectrum with the frameworks, languages and software we really like, they are done by people who really want their end result to have this quality of "good" and are very considered. They leverage their coding ability to great effect.
(lua and its implementation is a good example of this )
I think when we see your more run of the mill business app where you spec -> implement, often you don't see good programming, often because no one super cares. It's just average programming. However, when someone starts thinking, well, applications like this should be super easy to put together and really starts to care that they are easy to do, then you'll see some good programming :)
just remember I'm not saying caring vs coding skills.... I'm saying caring from when you are noob through to your entire growth as a programmer will define you as a good programmer, as opposed to an average one. An average one will also adopt coding skills and be... ok, average programmers will be inspired by good programmers and want to emulate them, "wow! that person did some awesome stuff with React!, lets do React! it is all things awesome!", but then you find while it's certainly got some things you appreciate, you end up with average React code because you adopted the the framework and not the mindset. My observation is good programmers start... and continue with a mindset. "It works" is never quite the goal, it needs this quality of being "good", good code, good design, good Ux, which we won't try and define, but more importantly is driven by caring about the outcome.
I guess that's more my reflection on my observations, what I have observed is having taken on people out of uni ( or crossed into programming from math / science / engineering ), and seen them develop over the years I have this sense of "good programmer" from the beginning, it's not once they reach some level of coding ability. They always do good things with their current capabilities. They then carry on and improve those capabilities and do even more good things.
On the other hand, the pleasure that a good piece of code in a beautiful software gives is something I can perhaps relate to an opiate high (as a metaphor, never tried honestly :) )
Other things - Android apps for example - tend not to give me this vibe. They feel more nebulous and "unfinished", like it's a miracle they work at all and will break at any moment in ways I couldn't understand.
Some places get it, some don't, some partially get it. One of the classic things I have seen is "managers" that say they want you to care but don't really care themselves.
Interestingly a number of years ago I went through a program called "Better by Design" which the NZ government sponsored for local businesses, see:- http://www.betterbydesign.org.nz/why-design-matters/ and a big part of the message about good design was really all about trying to make people care at every level of the company.
1. Identify what it means to be good
2. Work endlessly towards that aim
3. Deliberately practice
4. Decide to refine strengths or squash weaknesses. Do this as frequently as possible. Make sure you have an accurate assessment of what your strengths and weaknesses are. (5) and (6) can help with this.
5. Consult the advice of those more experienced. As frequently as possible
6. Allow your work to be publicly scrutinized. Do not work privately, the feedback loop should be as tight as possible to inform (1)
7. Repeat (1) - (6) as frequently as possible
Do that and you will become better. Guaranteed. Note, this won't necessarily make you the best. However, it will make you better. Continue this process until you're as good as you desire. There, of course, are diminishing returns after a while.
You'll never get a solid definition for a good programmer, and that's the problem. If we knew that, we would have a list of things to learn and teach and we could easily make that a standard interview test before giving people a job. And no one would need to write any more "10 things you need to know as a programmer" articles.
Answering all those questions for a given domain is how we have so many articles like this. Everyone has their own take, and it can be useful to look at others' so you can compare it to your own.
https://dimitrov2k.wordpress.com/2017/01/22/what-does-it-tak...
What I mean by that is that you don't expect some thing you just wrote to work the first time, and maybe not the second or third, and so on. But you expect that you'll eventually figure it out and it will work.
A short-term optimist would become discouraged by their expectations not being met over and over, while the long-term pessimist would not be sustained through the hard parts by imagining how happy they'll be when they made their thing work.
I think programming either repels people who are short term optimists or long term pessimists, or the process of learning to code transforms them into short term pessimists and long term optimists.
>The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless. By writing clear technical documentation for end users, they allow people to figure out what their code is supposed to do, which is the only way those users can see the value in their code. There’s a lot of wonderful, useful code buried on sourceforge somewhere that nobody uses because it was created by programmers who don’t write very well (or don’t write at all), and so nobody knows what they’ve done and their brilliant code languishes.
Obligatory Randall Monroe quote that hits the nail on the head: "I never trust anyone who's more excited about success than about doing the thing they want to be successful at."
If you're not passionate or enjoying what you're doing, you're probably wasting your time.
- You need to think a certain way. You need to be able to see how to translate a problem into something a machine can execute. You need to be able to switch from the macro to the micro smoothly.
- You need a certain level of proficiency with the tools you're using. Those can be programming languages/OSes/libraries/other software.
- You need experience. Having seen different approaches to solving various problems. Which ones worked. Which didn't. Having tried a few different approaches, different languages.
- You need domain knowledge. If you're working in a certain field you need to know the state of the art. You need to be able to read papers in the field. You need to be able to apply whatever techniques are required for the domain.
- You need to be a problem solver.
These are sort of basic table stakes for being a good "programmer".
In most real world settings you need to have some more on top of that:
- You'll need to be a good communicator. You will need to interact effectively with many different people, e.g. your boss, a product manager, junior developers. It's a team effort.
- You need to understand users/customers. You need to be able to gather requirements, ask the right questions, and deliver something useful.
- You need to understand the life-cycle of software. How long will it be in use? What sort of maintenance work will it need. How will it evolve?
- You need to have some business understanding. Is what you're doing creating business value?
- You need to appreciate the right trade-offs. Sometimes a crappy solution sooner wins over a perfect solution too late. And sometimes you should wait and have a perfect solution. That's just one example of a trade-off but our job is full of them.
- You need perseverance. Sometimes things take longer than you think. Some bugs take a lot of work to chase down.
It's just staggering how shitty a lot of documentation is. I can forgive a one-person github repo for skimping on it, but I get a little irate when I'm using APIs from Fortune 500s and have to resort to decompiling because their docs are missing, incomplete, incorrect, or otherwise hot garbage.
At the first company, a good software engineer was a person who could effectively work inside of the team and get through the requirements for code review in a timely manner. While working at another job a good programmer was someone who could figure out the requirements by themselves and have a working product to show the boss in a timely manner. At my current a good software developer is someone who has a strong grasp of their language of choice, can deliver features to a Product Owner, and who can grab a project by the horns and lead from an architectural or design perspective.
None of these answers are wrong, they are just reflections of the engineering cultures they are born from.
Based on my experience a good programmer is someone that understands what success means in the culture they are currently in and can execute on that. Long term a good programmer is someone that continues to learn popular skills, products, frameworks, tools and can continue to follow the path that best suits them, whether that be a startup, large corp, freelance, or entrepreneurship.
It's all about opening doors for yourself to walk through.
Learn to conserve your resources, learn to eschew that which is not needed, and for crying out loud learn to not write bloated stuff. Even today, most programs I use on Windows 7 were written back in the days of Windows 95/98 and they still work faster than any current modern implementation you can find, and they're smaller.
- support x64
- support new web tech like WebGL, WebRTC, Crypto API, all CSS options, the latest JavaScript specs
- update rendering engine for CSS3
- support retina/hiDPI
- handle webpages that are big in size + have loads of javascript libraries + multiple advertisement parties
- update to a modern UI
- implement new cryptos for HTTPS
- ship with lots of rejected certificates
- still support old systems
- do all this in a secure wayWhile modern tools and frameworks may sometimes feel bloated, they allow us to develop and iterate fast. I know I would've finished less projects if I had to be programming with performance and size in mind. For a lot of projects it just doesn't matter that much. It's more important that the job gets done.
And insecurely, at the same time. The majority of vulnerabilities today come from shoddy programming practices taught by the newest languages and frameworks.
I had the same insight after many years like the author - that every problem you do can be broken down into smaller problems, which can be worked independently and tested independently. Why it wasn't obvious to me early-on I have no idea. I guess I never developed the intuition to see the efficiency of the method. Did anyone else among you had the same experience?
Unless you delete or ignore "and tested" from that post, abc_lisper's approach definitely involves tests.
I do break down problems and follow the same kind of process, yet my goal is less automated testing than it is raw flexibility, ability to recombine pieces of code at will and move fast.
Chasing automated tests, even if it supposedly yields this kind of composite constructs is in my opinion taking an interesting side-effect of good craft for an end in itself.
Then of course, saying the code can be tested in isolation doesn't imply coding is driven by tests.
TDD, in my opinion, like all idols in the history of cults is, as an end, the dawn of critical thinking and progress.
At some point you have to ask yourself: If this "decomposition" hammer is the only tool we have to use in the world, it's no surprise that everything looks like a nail.
Agreed! I think this is why it was not intuitive to me. I was (reasonably) good at math in school, but I never tried to decompose the problem. I always tried to get a feel of the problem by looking at it from various angles and get the crux of the problem. That's the best I can say about my thinking method then.
Things got more complex. Named subroutines started seeming logical to encapsulate certain behaviors. Eventually, it became natural to think "I wish this part of the program were separated out and implemented elsewhere, so that I could treat it as a solved problem." That's about the point where a divide-and-conquer approach started occurring to me, at least in a limited context. That context expanded over time.
I think it stems from a few reasons - 1. I have a tendency to fix small problems that only need a one-time fix. So, lots of code, but disposable and messy. 2. HS programming classes lacked a lot of the meta stuffs, like refactoring, working in groups, etc. 3. Most of my coding years have been spent in a terminal where a combination of awk, sed, grep, xargs, etc works perfectly fine. A non-trivial number of problems can be solved that way, but it hits a wall pretty quickly.
For the past few months, I've been writing a lot of Clojure and have found that it fits my mental model significantly better than Python, C, etc. What's interesting is that all other languages I code in have dramatically improved ever since Clojure "clicked". Hell, even my bash-fu has become cleaner, terser, faster and more bug free. Funny how that works..
I think the reason it feels more natural is its emphasis on process instead of things. You think of computation as series of transformations, and that makes easy to establish causal relationships among events and thus help reason better about the system. (I think Steve Yegge first complained about Java, that it is a land of nouns)
I think the failing of OOP for me is that I never got what an object is! To me, an object always felt like a weird plane in a n-dimensional axes(because an object contains other objects), and it was hard to reason about that. For example, my first (atleast in my latent consciousness) reaction about Abstract classes was, what is it abstract about? If it is abstract about a bunch of things, that are only related because of the flow of code, I guess I wasn't smart enough to crack that effectively.
I've basically been mentoring him and having him read https://github.com/braydie/HowToBeAProgrammer , Comp Science with Python, and a couple books on linux and C to help with some lower level stuff.
He's been struggling a lot with C and Linux concepts. I've been there to help, and now I have strong opinion C and Linux would make a lot of programmers have a better understanding of their programs and computers.
Now, you can solve problems in many ways. They can be solved in the best interest of the programmer, or in the best interest of the company.
If I have a sales team, and give them a goal to sell $100, and they make a loan for $100 on behalf of the company and give me $100, that's probably not a good sales team. Let alone a 10x sales team.
But in software, technical debt (equivalent to buying with a loan) is something done frequently and some people mistakenly perceive it as being a good programmer. Usually because they cannot perceive the build-up of accrued work.
Mostly agree with that with the exception of learning new things. Sometimes it helps to be dogmatic about things if your goal is to learn something new.
A prime example is TDD. When my goal is to build a working piece of software, I tend to do TDD for some parts and write tests post facto (or not at all) for other parts. When learning TDD it helped to force myself to be dogmatic.
Similarly, if you're learning functional programming in a language that isn't strictly pure, its helpful to be dogmatic about your approach and force yourself to do things the functional way, while in the real world introducing limited impurities may be better.
I always read this... What exactly is a unit test? What parts of my software should be tested? What are some examples of good unit tests and the code that is tested?
Why does that matter? It means that you're writing a user of your class before you write the class. That means that the interface of the class gets designed from the mindset of a user, not an implementor.
More: The interface gets designed by someone who wants to be able to test all the externally-visible behavior of the class. If you can't test it, you have to think about re-designing the class interface - often by breaking it up into smaller classes. I've seen this in practice; the net effect of this is better class design (plus thorough tests).
That said, I'm considerably stronger of a proponent of tests than I am of TDD. If you don't like the TDD approach, still write tests. Write lots of them. They'll often save you when you make subtle mistakes in your next set of changes. (Nothing like fixing a bug, running the tests, and getting informed of all the implications of your change that you forgot about.)
> That means that the interface of the class gets designed from the mindset of a user, not an implementor.
From my experience, something entirely different happens. The class gets designed from the mindset of a third party - the tester. Which is, I believe, a mindset different from the user. If all you're testing is the externally-visible behaviour, fine. You're pretty much treating the class like a library. But if you start injecting stuff into the class to test if some other dependent services got called properly, etc. - and especially if you start designing the interface around such testability, then I believe it'll lead to bad, unreadable code. In particular, I believe adding complexity to the class for the sole purpose of making it easier to test is a code stink.
TDD taken to the extreme prescribes that you should only ever write dumbest possible code that makes current tests pass. If you need more complicated behaviour, you first have to write tests for it. But this gets quickly out of hand if your project is meant to do anything more complicated than being a simple CRUD layer, because test complexity rises in lockstep with production code complexity. I've seen cases when people blindly following the test->code->refactor cycle created tests that themselves were isomorphic to the algorithm they were implementing, which makes one ask where did they have the code that tested if tests themselves are implemented correctly?
So personally, while I like tests (particularly regression tests), I just can't make myself follow TDD.
> But this gets quickly out of hand if your project is meant to do anything more complicated than being a simple CRUD layer...
I've done things a lot more complicated than a simple CRUD layer. TDD held up just fine.
> I've seen cases when people blindly following the test->code->refactor cycle created tests that themselves were isomorphic to the algorithm they were implementing...
Well, blindly following any methodology is likely to get you in trouble, one way or another. The problem is blindly following, not that they're following TDD.
That said, I did TDD, and now I don't. It worked well for me, I loved the kind of code that came out of it, and I still don't do it any more.
What parts should be tested? Everything that can be conveniently tested, and some distance past that. The goal is "every externally visible behavior of a class"; that is, everything that matters to a caller. For example, let's suppose I have a "sorted container" class. I'd want to test that it returns stuff in sorted order, maybe with two or three items, and with lots (hundreds or thousands). I'd want to test that it handled duplicates correctly. I'd want to test that it worked correctly with only one item, and with zero. I would not want to test whether it was internally implemented with a vector - that's not something that the caller cares about. So if the sorted container is changed from a vector to a tree, the unit tests should run unchanged.
Just last week, I was breaking apart a singleton into three related singletons. "Related" means that they each need a reference (or pointer) to at least some of the others. Turns out I coded a recursive constructor loop. A unit test pointed that out to me.
I've seen unit tests catch race conditions. Catch that I was calling a pure virtual method in a base class destructor. Plus of course all a whole bunch of the usual regular bugs.
You should have thoughtful integration tests. Unit tests are only useful when you have an obvious independent "unit" with semantics that are completely independent from the rest of your code. If so, you test those.
If you want to make sure your functions work, write unit tests.
If you want to make sure your application works, write integration tests.
The easiest examples of unit tests are math functions, since they're so well-behaved.
Here is a square root function in Javascript:
function sqrt(n) {
guess = n/2;
while(Math.abs(guess*guess - n) < 0.00001) {
guess = (guess + n/guess)/2;
}
return n;
}
assert_equals(4.0, sqrt(16));
The call to assert_equals there is a unit test. (Also, keep in mind that assert_equals is a glorified if statement)
"well, what isn't a unit test??"
Since we can call anything we want a unit, the answer is "whenever we say we aren't doing a unit test". But a more practical answer is: whenever you're testing the interaction between two or more units (where a unit is a function/method).
If you're making a video game, you might have enemies who can jump, and guns that can fire. It would be a unit test to check if enemies jump correctly, and it would be a unit test to see if guns fire correctly. It wouldn't be a unit test to see if guns fire correctly from a jumping enemy, since this is the combination of two pieces.
Another way to (sort of) define a unit test is to say "how does this behave assuming that the rest of the system is correct"? That is, we aim to check the behavior of our code in isolation from the rest of the system.
This is important when something is wrong, because if we know what is behaving correctly, we don't have to waste time checking if it's the cause.
I've been programming professionally for 6 years and I'm learning as much today as when I started.
I have rarely had problems from being too simple, and when you do they are easy to fix, but over complication (over generifying) is always a beast to fix.
https://www.oreilly.de/buecher/120174/9783897215672-weniger-...
I think it is only available in German.
I've noticed developers who can quote scripture (best practices), but can't solve a non-trivial problem.
Adderall or something like that could also be a plus...
If the programmer can't tell the difference when implementing, then go for a simpler version, as you suggest.
- Elegant: Nice, clean, well thought out.
- Clever: Hackish, terse, too hard to understand for whatever benefit it brings.
Don't be so arrogant that you stop improving or fail to understand mistakes, but by all means don't be humble. Be proud of who you are and the work you've done. You work in an industry where 90% of people don't understand what you do. Chances are your own boss won't understand the actual value you're providing.
So don't be humble. "There's always someone better than you out there" -- sure, but that person's not here, right?
this is the author mean for "humble", and I think it's damn true
Great response to a devil I've had on my shoulder for a long time.
The best advice is just to become as best as you can by trying as much as you can:
1. Deliberately working
2. Learning from people you perceive to be better.
3. Keeping up with trends.
4. Mastery of the basics/fundamentals.
5. A razor sharp focus on what really matters -- value in the context of the business/domain.
This is a tricky part, and you have to ask yourself explicitly - what do you want to work on? Becoming a better programmer, or a better employee/entrepreneur? Because business does not optimize just for good, quality work. It optimizes for earning money. Which involves things like:
- doing good, quality work which can be sold
- doing good enough work, minding the essential tradeoff between quality and business realities
- doing shitty, half-assed work and having a good sales team sell it anyway
- doing useless shiny things that don't really help the intended audience, but help your business to get their money
If the needs of your business are from the latter two groups, being a good programmer goes directly against your career success in that place. Unfortunately, it is my belief that most of the jobs in our industry fall into those two groups. From the POV of everyone else but programmers, the code is only means to an end.
I want to emphasize it, because a lot of advice for programmers tells you about the "razor sharp focus on what really matters -- value in the context of the business/domain", and I found that for some reason, it never resonated with me. It took me a while to understand why - it's because this advice comes from a business mindset, where making money is the goal and the means to it are tangential. I have the opposite mindset - for me, it's the product that matters, not how to make more money off it. Realizing that those are two different worldviews has helped me stop feeling inadequate just because I couldn't bring myself to enjoy the business value. It also helped me understand the POV of management and what they expect from me.
I think it interacts well with the concept of “strong opinions weakly held”. Have a strong opinion that you've built a great thing, but hold it weakly so that in the face of clear arguments or evidence that it is in fact not great, or that another solution is better, you can admit it and adjust. This, to me, is the right balance of confidence and humility---in programming, as in life.
So many people miss this, unfortunately.
I agree with you in principle, but again, I don't think that's a winning strategy.
A humble, competent woodworker creates a piece that's beautiful, visually rich, has a solid, study feel to it, and can be appreciated by most. The software engineer, who checks in a fix on the back-end service that pre-empts several bugs that had yet to be discovered, goes relatively unappreciated.
So can one be humble and confident? Yes. Will it be understood and appreciated from the outside? Probably not. Is it a good strategy? Probably not.
I'd say a person has three options:
1) work for people who are technically competent enough to understand the true value of your work. In my experience, this is pretty rare out in the real world.
2) become a salesman and sell yourself at all times. This seems fundamentally opposed to dominant personality types in software.
3) stop being so humble and be proud of your work. This seems like the most logical choice to me.
Our industry is rife with imposter syndrome, legends of the 10x engineer, impressions that everyone else is succeeding flawlessly thanks to polished blog posts and GitHub portfolios [1], and endless pontificating on things that often boil down to fashion and code style. I don't think we need anything telling us to be more humble.
You may be a completely average engineer writing CRUD software for some local bank. Yeah, maybe that guy blogging about his work at Google would do a better job than you. But he's not here, and your the best you company has found. You're valuable and capable. Be proud of what you've accomplished!
[1] - people have written recently about how Facebook causes negative feelings since you seem to see others only at their best. I think this is normal folks finding out what tech types have experienced for decades, but nobody has ever talked about it.
Fundamentally, I agree that you should be proud of what you've done, even if 10X awesome dude at Google could have done better. For one thing, 10X awesome dude at Google is surrounded by other Google folks, and by 15+ years of Google technology. There's being aware that there are better possibilities out there---indeed, being interested in them and even thirsty to learn more about them---and there's being embarrassed about what you've done. You can be interested in the crazy things some people do and want to learn more about those things while still working at a smaller, more limited scope and being proud of what you achieve with what you've got. The latter is how you get confidence, the former is how you get humility.
In short, I think we're probably saying the same thing. When you build a thing, you should be proud of that thing---unless you deliberately cut corners for some other tradeoff, in which case you should be cognizant of why you did it and satisfied with the tradeoffs you made. But that doesn't mean you have to think there's no better way, nor even that you have to avoid looking into those better ways. Often, I think these things (thinking there's no better way, not looking for improvements) are what people mean when they refer to folks who aren't humble. Certainly, that's what I mean.
I think that the "be humble" criterion makes sense because it is directly correlated to the awareness that there is no single right way to do something. Changing requirements can pull the rug from underneath you and turn a good idea into a bad idea.
Software engineering is a bit like economics; a lot of people think that they understand it, but in reality nobody does.
Now, even if the minority of developers have coded a few modules that look absolutely elegant and neat, it interacts with the majority of the software that is complex, ugly and sometimes bloated. On top of that, in many teams, developers often touch each others' code and modules to make bug fixes, enhancements, etc. which means all code (whether currently elegant or not) tends towards ugly.
How, under these circumstances, do you maintain your motivation to write good, clean and elegant code after having worked about 10 years in the software industry?