Does someone have a problem? Can you build a solution to that problem? If not can you learn to build a solution to that problem? Once built, can you learn to improve that solution?
The best advice on the profession that I was ever given was simply, "Learn to learn."
The vast majority of this profession is just being interested in figuring out how to solve different problems. Sometimes that means it's all you and sometimes it means learning new things or doing research.
You know that you are not a good programmer when you don't see any problems that need to be solved.
I couldn't agree more. It's all about problem solving. The coding part is just how you do it. If you have to be told how to write code or architect a solution, you are not a good programmer... yet!
I'm sure others can do a better job elaborating on this process. I only recently made a mental switch to treat programming as a thing in itself that I enjoy, and it really has made me a happier person. I'm learning faster and more than ever before (even with coding as my only source of income, which should have provided incentive), I'm having an amazing time exploring things for the sake of just exploring and learning.
And as a bonus, it has made me both enjoy and do better at my job as well! I feel like my toolset has rapidly expanded, and as a result I can (justifiably) use those tools to help clients (and get paid), scratch actual code-solvable itches I've had for years, and see potential ways to generate recurring income. And, with some trepidation, I even think I've learned at least some things that I can use to 'make the world a better' place!
EDIT: more specifically, aside from looking for problems to solve, I decided to create my own problems, or consider them worth solving, and then went and solved them.
If your code is bulletproof and you don't have any problem to solve then you move onto the next piece of software, I've never heard a programmer saying he has too much free time and not enough projects to work on.
There are 2 types of “good” programmers, who both think the other type is useless.
The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degrading the code base. But their boss will love them because they deliver the shiny when required.
The second type are the ones who can sort out the mess created by the first type without making things even worse. They tend to be less visible, less well paid and less in demand but every company needs them.
The whizz kids and the grown-ups basically. Companies who only have the first will burn bright but not be able to scale. Companies who have only the second type tend to move too slowly to get to market or pivot.
So ideally there is a symbiotic relationship between the two types and someone who is a combination of the two is very rare indeed, because the first either needs an ability to place limitations on awareness of the big picture (and it’s very difficult to create a blind spot on demand once you have experience) or they need to be incredible at both analysis and full stack execution. Those people are few and far between so a process that gets the best out of the two types is, in my experience, the way that most companies work.
While I appreciate you sharing, I have to say that I believe this is extremely non-representative of the industry. I've work on a lot of teams across the years and have seems different people with each of those individual qualities, but have never seen any common split of people into those two combinations.
I feel this may be too specific to your personal experience / work history.
I don't know if I agree. I have friends that can smash out amazing code in very little time.
Looking through some repositories of programs I like, some of them were prototyped in very little time, but with a surprisingly excellent first revision.
I had the pleasure to work with Zed Shaw quite some time ago, and even though his code might not be perfect, he writes a lot better code than the vast majority, in a lot less time.
This is interesting to hear. I thought Zed's book on C programming was reasonably good but I lost an awful lot of respect for him with his strange and nearly incomprehensible tirades against Python 3.
LOL. An account with these as the only comments and no submissions? Man this place is so weird. It's like you're at a party, and then some guy can scream at you from across the room while wearing a Richard Nixon mask and everyone goes "Oh yeah that is true." Never questioning why the guy is wearing a mask at a party.
Anyway, I think you need to look up the words "tirade" and "incomprehensible"
Looks like you got some haters... The only reason to make a throw away in order to bash you - deservedly or not I don't know - is because you know this person and they don't want to remove their Nixon mask and risk a real life confrontation.
I did not create this account as a throwaway. I just don't have the inclination to comment on HN much and was lurking for a long time until recently. As proof I point you to my Reddit account of the same name which has a great deal of activity and which is reasonably well recognised and regarded in certain communities. I say this to demonstrate that I am not creating burner personas for the sole purpose of starting flame wars - but I did think it was worth stating in this discussion that Zed has succeeded in discrediting himself in some programming circles.
Someone linked me here asking me how I can write good quality code so fast so I thought I would come and drop a comment just in case other people read this and fall prey to the "HN must be true" virus.
I have no idea if I write code better or faster than other people. Maybe I do, but I always think that I don't write very good code most of the time so I have to be extra careful. I spent a lot of time writing code very slowly and being extra careful so that I could make sure it's good quality. I guess after focusing on quality for so long I just got faster at it compared to others. But, I'm going to guess that I actually am not much faster than other people.
Yeah this was my thought too. He described the two types of Junior or intermediate programmer but there's a third type that writes great software extremely fast. I've worked with them before.
All the founders of Autodesk were of the second type. Most were mainframe OS maintenance programmers who fixed kernel bugs in assembler.
A big issue for AutoCAD was "don't lose the user's work". Customers were not forgiving of that. New features were less important.
Autodesk is still around, market cap around $26 billion. They're still selling expensive software that works, and have been profitable for over 30 years.
Just a small comment on AutoCAD. Any software product that's successful for 34 years is pretty impressive in my book.
3d apps especially seem to suffer from bloat, which then leads to competitors getting the leg up and the original dying off; then repeat for the competitors.
In practice you might have tension on a team between those who favor speed vs stability, but I resent the characterization that it is an inherent trait of the programmer.
If you want to be a great startup engineer you have to exercise judgement; knowing when to do something quick and dirty, what to polish, what code is likely to live a long time, when and how to address various aspects of scalability, etc. Someone who just has one mode of operation and does not consider the context is always a liability unless their role is very rigidly defined and management knows what they're doing.
In my experience everyone has a natural mode of working and the conundrum for management is do you try to get people to change (to become all-rounders) or do you develop people in the direction they are already headed and therefore encourage specialisation? In my experience it’s sometimes better to let people be the best “them” they can be, than to try and require them to change and lose their uniqueness.
I think most developers naturally become more cautious with experience (the bitter experience of debugging long into the night usually), while some never grok maintainability or documentation but can still be highly productive net contributors if you have a great testing team between their code and your customers
I agree. The most important quality I try to cultivate is what I guess many would call 'good judgment', and others 'intuition'.
I've worked as a freelancer, lead front-end developer, and contractor, and ranging from 'stuck in the nineties' to 'use whatever HN talks about for the front-end' companies. One of the most important lessons I learned is to use the right tool for the right job. Also to not let 'purity' or 'elegance' get in the way of getting it done (which is difficult for me). But also to never confuse 'getting things done' with laziness.
That sounds arrogant and condescending. I don't think that you should have a ship-at-all-cost attitude, notably when it comes with creating an unmaintainable kludge, but the second type, the meticulous kind, can also be ones who over-think every aspect of the output without taking the first step, which benefits no one.
There's actually a lot of truth in what he said. You need both types - the mix depends on where the company is in it's life. Early on, you need more of the "rockstar" types because shipping is life. Later you need a blend with more of the latter type, because existing customers will only put up with bugs for so long, and expect to see new features they asked for.
I've been the latter type in the early stage of a startup, and even though I strongly believe in my more cautious approach to programming, in general, in hindsight I feel that I should've abandoned that caution or that they would've been better of with another programmer.
Thankfully I'm pretty sure the startup would've failed no matter what, so I don't feel too guilty about it. But it taught me a valuable lesson.
Arrogant and condescending to whom? I said that both types were necessary to succeed exactly because I know the “over-thinking” types can be just as destructive to a software business as hackers who only think short term. My point is that you either identify and hire only unicorn-perfect developers, which you will probably never be able to find enough of, or you build a process that balances the strengths and weaknesses of your varied team members against each other, so that you get a workable happy medium between “move fast and break stuff” and “move slower than the market requires and don’t break stuff” in leiu of being able to hire one infallible genius after another.
Sounds like you've worked with quite a lot of wannabe rockstar programmers. Look, you're not wrong - there are certainly mediocre programmers out there who have decided that quantity is its own quality, and can bang out lots of buggy code really quickly. However, just like there are a lot of middling to good musicians out there, but only a few truly great ones, there's something that separates the good from the great, and the same goes for programmers.
Unfortunately for us mere mortals, programming is not quite a performance art (despite the existence of /r/watchpeoplecode), so there's not anything to point at globally as this is what a great programmer looks like.
Moreover, a company's culture is the culture - if they put up with assholes who can program a little bit, they'll also put up with assholes in be other positions for different reason.
Full of bugs (non working) functionality that constantly causes customer issues is not considered "rockstar". It might appear that way up front, but the lasting reputation will be from the success (or not) of the final product, including whatever post-deadline work is done.
Lots of us are good at being excited, moving fast, when something grabs our focus. Some of us are just as excited at the quality of our "how" as we are the size and shape of the finished "what".
I'm type 2, I like fixing things though I just inherited a system that is so bad I'm struggling to figure out where to even start, might be the first time in my career where a rewrite might make sense.
Let me guess, you feel you're in the second category? You know it's possible to draw distinctions between different methodologies without disparaging the one you feel is different than you.
The best programmer is the one who can solve the problem effectively and efficiently without even touching the keyboard.
You don't have to be "good". You have to solve the right problem efficiently. Find the right problem and be the solution. If you need to write a program, make an easy one. Easy to use and easy to maintain. You'll get what that means after a few years of maintaining. Nobody ever cares if you're a "good programmer" or how you feel about yourself.
What you describe is application and systems architecture and requires domain knowledge. Excellent programming requires the ability to create a functional blueprint in whatever way/shape/form is decided and do so without undue time and cost.
Maybe programming is to system architecture as tactics is to strategy. Which would probably mean management is to system architecture as logistics is to strategy?
I couldn't agree more, as a programmer you get assigned tasks because non-technical people think throwing software at a problem solves it, good programmers can solve problems with code, the best programmer is the one that can identify when code is really needed for problem-solving.
Depends how you define good. Some define good as getting the job done in a quick and efficient manner and making the client (or company) happy with the result, however code quality may suffer in this instance and it could be hard to maintain. Others define good as writing the highest quality code with high test coverage, deployment procedures, writing detailed JIRA tickets, great documentation, training other developers in the team on the system, making the front end pixel perfect, recommending and implementing better features and improvements into the project, etc etc. As you can tell these people may suffer from inability to meet deadlines and getting things out the door.
Ideally you walk the line between them both. Personally, I'm in the former camp, but I'm more a business owner than a coder, so deliverables are more important than the best programming methodologies. It depends on what the priority of the business/department/team is.
Why not just build code efficiency requirements and correctness into the spec then? Hah, I'm just kidding, I've worked long enough to know no one ever has a spec. (I've heard things about various NASA projects but have never worked there.)
What is this deliverable for? TechCrunch Demo? The only metric a demoable build, and even then people understand it'll have bugs.
There are still places where there's a drop dead date for code (firmware; physical media) but continuous deployment on the web turns that on its head - the software is constantly evolving; there's no single deliverable that's set in stone and can never ever be changed.
Developer hours is a very limited resource, better to launch the product with slow code and parallelize thanks to the cloud and optimize once hotspots are identified.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -Donald Knuth.
I've worked for a startup where the plans changed enough to have significant effect on the code. Rewriting a lot of it ended up being necessary and actually well-justified.
As a more careful programmer, I wasted everyone's time making 'the right choices' when in this particular context, in hindsight, I could've known that rewriting the whole thing was a likely scenario.
If I'd get the same job now, years later and (I hope) wiser, I'd have built a much quicker, dirtier, buggier version (essentially a prototype/alpha) instead.
I don't think there can be an absolute measure of how good of a programmer one is; it is a function of how well acquainted one is with the problem at hand.
A problem is not only defined by stuff like the core routines of the program, but also everything surrounding it, like the structure of the code and of the program as a whole, the environment the program is supposed to be running in, and how to collaborate or manage the other people who are working on the program. Though at this point it's probably better to use a broader term like "software engineer".
A programmer who has enough experience across the whole stack for a certain problem is going to be able to deliver good, readable and efficient code in a timely fashion.
Good programmers manage side effects. They have an idea of what kind of side effects a particular coding strategy or pattern is going to tend to produce. They understand the range of bugs they are likely to encounter with an implementation and shore them up quickly.
Likewise, they also tend to produce more desirable side effects - things that maybe weren't described in the spec but are a noticeable improvement (e.g., responsive UI behavior)
I think there are different ways to be a good programmer, beyond basic intelligence and diligence.
In security and high-availability related environments – where I've spent most of my time – it is important that you validate all ins and outs, system and function returns, check if writes succeed, in short, not unlike a chess player, to be able to fit all possible moves and scenarios that could go wrong inside your head. You probably need to naturally possess a mind that is precise and can find all loopholes.
Another way is to see efficiency through layers of algorithms and realities of real-life systems. Universities focus too much on mathematical formulas in my opinion; real systems are not clean and simple like a math function with few variabes. To understand by experience where complex systems with remote databases, shared disks and network can go wrong and write code that foresees, prevents or deals with unexpected complications is an important skill that sadly enough is hard to quantify on a resume. A lot depends on experience and knowledge, but you need to have interest and curiosity to get there.
And finally, you have those programmers that can create a more-or-less working mock-up in mere hours. In my experience, those are not always the people that want to spend a year ironing out all the bugs, but it is a valuable skill to be able to adapt and churn out something fast and iterate on it. Dare I say, the Javascript mindset. You probably need to be pretty enthusiastic about new technologies and quick on your feet.
To find not only a motivated person but the right "type" for a job position is probably not an easy task, just as it is hard for a programmer to find the right job that fits your own particular strengths and way you like to work. You might be a good programmer, but end up in the wrong environment. If you are a thorough and perfectionistic person, you're probably not going to be happy in a mockup-a-day start-up.
> Universities focus too much on mathematical formulas in my opinion; real systems are not clean and simple like a math function with few variabes.
How many variables your functions consume depends on how much you split them up, although you'll of course end up with thousands of functions for a real application, if they each consume ~3 arguments. So, in other words, the limitation is to what degree your language enables you to split up your application in tiny, obviously simple fragments.
Mathematical functions can describe anything. Haskell consists of mathematical functions, and is Turing-complete, and because of its purity makes it easy to split up your functions into tiny ones (or at least sufficiently small).
For example, this[1] module is a Bitcoin payment channel server I'm writing in Haskell. The module describes, mostly at the type-level, three different Bitcoin networks (live, test, test-derive), and presents an interface to the Bitcoin network, which either fetches information from the Blockchain or deterministically derives test transactions.
Everything can be split up into tiny pieces like this, it just takes time, as the purity prevents you from utilizing loopholes that later turn out to be unmaintainable. It forces you to understand the essence of what you're trying to describe, because otherwise you can't capture all the invariants properly without too much duplicate code.
I think we're talking on a different level here. I'm rather thinking about the performance from an ops perspective. If you write highly specific code that runs close to the processor, of course predictability improves. But if you write a web application, possibly running in a virtualised environment, using remote databases and other network services, good look predicting performance to the end user. Even talking about tight loops, you simply can't predict if it will go and stay in the processor cache in layered, multi-tenant situations like that.
There is little correlation between theory and practice of a complex system when it comes to performance and reliability. For example, big-O notation tells you very little about the myriads of wonderful ways systems and networks can crash and burn. Disks never failed in my university classes. The more you know about the difference between a perfect theoretical system and the harsh randomness of a real one, the foresight of experience, the better a programmer you are, and this is not generally knowledge that comes from formal education.
In short, to be a better programmer, you need to know the difference between the best case ideal scenario and what is actually going to happen, usually when you least expect it...
No intrinsic quality makes you a good programmer. If you enjoy it, you'll develop solutions to problems that computers can solve. As you develop more, you'll become better.
Along the way, you'll develop a curiosity about solutions other people developed, so you'll read code more. Simultaneously, you'll develop curiosity about different tools, e.g. programming languages. This will lead you to explore them more.
It's all enjoyment feeding curiosity and lots of practice.
I'm watching my daughter's friend become a great basketball player. She's not inherently great at the game. She loves it and practices several hours daily in a disciplined manner. When it rains she puts on rain gear to practice. When it snows she shovels the driveway to keep practicing. She carries a notebook everywhere to diagram plays when she thinks of them.
Great programmers practice even when no computer is in front of them.
If you produce code that works with few or no bugs and is easy for you and your colleagues to maintain and fix, then you're good at programming.
Being a good coder is different from being a rock star coder. In fact, rock star coders can be terrible coders and yet have large followings. Most rock star coders became popular through blogging, tweeting, hacking and/or writing trivial software modules that are widely used. Coders who work on difficult problems don't usually become rock stars.
A good programmer always looks at the bigger picture. They understand when SOLID is appropriate and when "worse is better". A good programmer is familiar with the best practices and guidelines and principles, but always question them to understand their context and limitation. A good programmer understand that all tools and techniques are means to an end.
Great phrasing. Context is key. There are absolutely times when throwing together a quick solution is better than seeking an optimal solution. Because sometimes it just simply does not matter and you can spend your time working on more impactful items.
You're not good at programming - you should embrace that. I suspect many others here hate the code they wrote 6 months ago. I find that's about the amount of time it takes for my craft to be elevated to a new level that makes the differences obvious.
It's not about being good, it's about doing your best and improving every day. Sometimes it's about doing what others would consider bad. Pretending to be perfect is the opposite of progress and evolution.
You know you are a good programmer when you know what over-engineered code is. Let me explain.
The one and only metric is: how quick do you ship. I know what you think: this leads to unmaintainable code. That is wrong because a programmer who produce unmaintainable code doesn't ship quickly, by definition. Thats because programming works by iteration, and then it doesn't matter you can ship one iteration quickly, what matters is that you ship iterations quickly, over and over again.
Now, the game is simple, you can do two kind of mistakes: you can ship too "quickly" by writing rushed code, or you can ship too "slowly", by writing over-engineered code, for a given iteration. If you rush one iteration, you will have technical debt for the next iterations, and if you over-engineer one iteration, you are wasting time AND you are piling supposedly well written code which has no value and gonna stand in your way on later iterations (it always do, thats what level 2 programmers dont get). Of course, and thats the best part, programmers in practice tend to do both mistakes, which confuses them squared: they have a fair amount of technical debt in an over-engineered codebase.
Programmers in their career though tend to first do mostly rushed code (level 1 programmers) and then they do over-engineered code for the rest of their life (level 2 programmers). So you know you are a good programmer when you know what over-engineered code is.
Is the code readable?
Sorry this is just way to subjective. What you want is a code that's easy-to-learn. The difference? Easy-to-learn is really powerful while "readable" is not. That's because programming doesn't happen on your screen, programming happens between your ears. But first, a spectrum again, at one end you don't know anything about the code you have in front of you which means you cant do nothing; at the other end, you know the whole source code in which case you can do everything: fix, rewrite, extend, debug, run, anything.
A code that's absolutely obfuscated by all standard isnt easy-to-learn, so dont worry, yes "readability" matters of some sort. But a super readable code can be crap too, because it can just be as obfuscated as the former, it's just another form of obfuscation: flood.
A code written to be easy-to-learn means it has been written to help you getting closer to "you can do anything in the code" as quickly as possible. And guess what, the closer and quicker you are from being able to do anything in the code, the faster you ship. Rinse and repeat.
Depends upon what is programming? I think it's more like painting. Are you good at painting? How can we define it? If you know to hold a brush you are probably a painter. Are the best artists that get paid more? Or is the ones that are at the right place at the right time?
Back to programming, I feel that web development gets more credit, and as a web developer I can say that most of the development is just boilerplate configuration, made complicated by layers upon layers of unwanted but unavoidable complexity. On the other hand system programmers and game developers do more hardcore programming stuff, but may not be as much recognised outside their closed community.
So in other words depending upon the domain, a good programmer might mean a person who can figure out the configuration better and keep things nice and tidy (read 'standard') while at some other domains it might mean hardcore analytical capability and number crunching..
Coding is not enough. Is your code maintainable, interoperable? Did you ship?
What are the priorities of the project? Is your code formally verified not to have bugs? ETH just had such a bug. Has it been tested at scale? Twitter used to have fail whales.
Does your product have a community? Do you manage teammates well?
People live lives, companies build products. Ask yourself, "is my company building a good product?"
To me, someone who is "good" is just someone who has learned the language and main paradigms / tools for it, and can pick up new stuff fast. It's like a native speaker of English who can understand what you're saying and write a book on a new topic that goes over well.
Good means less bugs, maintainable code and playing well with others.
But you can know if you're bad at it. It's kind of like testing and other forms of QA in software -- usually they can attest to the presence of bugs, but not their absence.
If you find yourself not falling into the pitfalls of a bad programmer... odds are you're not programming enough but if you are doing it and avoiding those pitfalls, you have a chance at being considered good. If you have enough self-awareness to watch out for pitfalls you might fall into and avoid them in the future, you will become better than you are now. And that's really all I can promise you.
>Identify the knowledge you lack and seek out the most relevant resource
That can be difficult on the Web.
When learning electronics searching the Web for help quickly showed how useless it is. There were many explanations but no teaching and often the explanation begun at a level too far past the level of the question asked.
My guess is well over 95% of explanations I saw were just people posturing to show off their knowledge. Wordy explanations that went on for paragraphs never teaching just saying things.
I craved brief answers that taught not explained. I know 2+2 = 4 but how do you know that how do I learn to know that!
> When learning electronics searching the Web for help quickly showed how useless it is
Not just electronics. When you're dealing with any kind of non-trivial problem, searching for help with sensible solutions from internet is an exercise in frustration and futility. The answers, when you find any, tend to be out of date, ill-informed or just flat out wrong. Often all three at the same time.
Simply put: most of the technical information on the internet is written by helpful idiots.
Out of interest what did you feel was lacking about electronics information online? Personally, I've always been bothered by how scattered the information is. One site has amazing amounts of detail on one thing, but often you have to flick between forum threads, random repositories and blogs to solve problems.
It seemed like every site showed you the answer but not the steps to get to it which is useless. It seemed as though people were trying to help by giving the answer but just giving the answer isn't helping.
The answer of one single problem is of no use. Another simple example imagine you want to know about multiplication say 5x5 but each example tells you the answer but not how to determine the answer. Knowing allows you to find any problem one example done for you does not.
Sites like the stackexchange network were OK although quite a bit of posturing as I call it and verbose rambling answers. Or worse a good tutorial but closed for apparently no reason.
I ended up at allaboutcircuits.com it was nicely laid out and with video tutorials. It supplemented what I was learning in class.
Poor analogy on my part I guess I wanted to use an example so simple it would be clear that seeing the result wasn't my goal knowing how to get to the result was what I wanted to know. Telling me the answer to a problem isn't helping me teaching me is helping me. The "give a man a fish he eats for a day but teach a man to fish he eats for life" philosophy.
Programming is a skill and a talent, like being a musician, chef or a ballerina. We all have our preferences when it comes to evaluating a performer. There are still customers in government that frown at your mac (because only windows computers are real computers), or think less of your skill overall because you can program in JavaScript ('not a real language'). They are idiots. But they also control the money, and they are also people who don't understand the narrowness of their view.
Meanwhile, there are countless grateful, happy customers who think the kid who slapped together some PHP templates hosted on a slow, insecure $2/mo shared WordPress host is a genius rockstar. This is a more defensible position; it's just also a landmine if the business grows a lot, because any mass of PHP has a limit of how much complexity it can absorb before breaking.
Enterprise customers are particularly hard to generalize over, because each enterprise's software is like a factory, where all the equipment is totally custom made, with all kinds of quirky weirdness that may be part of the secret sauce that makes things work, and no-one really knows if it is, but just keep things working. (Actually it may be larger than a factory, including multiple factories and some supporting supply chains a la Shenzhen).
You are good, if you question and revisit your assumptions on a regular basis, because you instinctively know, that there is a simpler and cleaner approach - it is just (with good reason) buried under business matters and deadlines.
If some % of changes you make to your code are towards a simplification, I believe you are on the right track.
Not so good programmers fix their assumptions (because they need some ground to stand on) and then let a project ossify - these become legacy systems, burden, technical debt, and so on.
Another angle: A good programmer will save you from problems you didn't even know you are going to have (and you will probably never noticy it, because she or he will have your back).
Yet another take: A good programmer will find a solution to a program which is either perfect or not perfect but so clear, that another person can use it as a basis for a better solution. A good programmer shortens the way to the things you want to achieve, in any way (perfect solution, good solution and clear problem picture, communication, better documentation, explanation, more performance, rethinking, disruption, calm night shifts, and so on).
Besides: Programming and development is actually very hard, many brilliant and curious minds haven't searched for another occuption after they started programming.
I'm looking forward to the day when we can get over our collective need to shore up our personal confidence. Reading through these comments might leave someone thinking that everyone is a good programmer, that just by wanting to learn code you're entitled to receive a participation trophy. We don't really need to handhold people.
Did you get a computer science degree? Did you land a job at a good company to write code after an extensive interview? Have you been able to keep that job for a few years? Have you written code other people find valuable? Do other engineers you respect commend you on your contributions?
If you've answered yes to all of the above or at least some then congratulations you're a good enough programmer. If not then there's room to grow and you can become one. Either way I laud you in your choice of career. It's a good one, and there's no reason to be handwringing about where you fit in the spectrum of engineering skills.
It's not just about confidence though. Yes, for some people, the question of whether they're a good enough programmer might stem from (social) insecurity, and I think what you're saying might be a very good answer for them.
But others, including myself, ask the question because we want to, as you say, 'always be learning'. We might be insecure, for example, about getting stuck at some equilibrium that isn't optimal, and just fishing for where to go next.
For example, it was through similarly-themed threads on HN that I learned about functional programming. I learned how important immutability might be, and to try and keep my functions and methods pure, even if I'm not going all in on the functional stuff.
Hell, even just thinking in terms of separating data from code was a revelation that I might have missed without HN functional weenies constantly submitting articles that boiled down to that as a point.
Anyways, not disagreeing with you necessarily, just nuancing.
I don't think it is that simple, good enough doesn't mean good.
It's easy to fool yourself if you're just getting by work day to day thinking everything is going well until one day it isn't.
Validation might be vanity but feedback is important. Trying to figure if you are a good programmer is the first step to actually being good, willingness to continuously learn and self-improvement is a key trait of good programmers IMO.
> If a programmer can’t produce good code, they aren’t a good programmer.
Who cares about good code ? good code doesn't mean anything, the only thing that is important is working code.
If your program works but the code is not "good" people will still use it.
A good programmer is someone who is able to write code that works
I care about good code. A caveat: I define good code as code I can come back to in a year and easily read and understand it.
Sure, come code you write once and never have to touch again. But that's usually the exception; popular programs always have more feature requests and bugs and have to keep up with the changing input/output environment. If it's bad code it will fall behind and be forgotten, because it's just too hard to maintain.
Have you heard about concept of code rigidity, fragility, immobility and viscosity?
You may have a piece of code that works now. But if it is rigid changing anything will be hell and require touching almost every part of the code. This of course will eat up time.
If it works but it is fragile, changing something in one place may break something else in very different place.
If your code works but is immobile, you will have to rewrite it if there is similar need in another system, but your code is not easy to reuse.
If your code works but has high viscosity future changes will be most likely done as the ugly hacks which won't help with any of the features listed above.
(I've omitted three more characteristics, because they are more of the result going overboard trying to avoid these four).
So to answer who cares about good code: anyone who will have to deal with it later.
I have worked on code that was working, fragile, rigid, and viscous, all at the same time. Clearly someone didn't respect those principles yet still produced code that works.
Readable code may not be good code. More readable code almost always means less efficient code. Readability is a trade off.
> Is it easy to extend?
Changing requirements are a thing for sure. But in almost every cases I came across, planning for shifting requirements always misses the point. It is much better to stick to your current requirements and keep your code simple, than introduce things that complicate your code for requirements that may or may not happen. Extending simple code is simpler than undoing code and replace.
> Is your code efficient?
It's very hard to self determine whether one own's code is efficient. Almost every one will think their code is efficient.
> can you write it quickly?
Again people tend to think that they are fast at writing code whatever their actual speed.
-- the reality is that it's really hard to qualify good or bad code. Self assession is particularly useless.
"More readable code almost always means less efficient code."
Can you give examples? I'm not sold that the "low hanging fruit" of readability improvement (empty lines to break up "paragraphs", breaking up unintelligible one-liners into several lines, etc.) degrades performance. My intuition is that the compiler/interpreter ends up producing almost identical runtime code and therefore similar performance.
Unless you mean more along the lines of expressivity (i.e Python and Ruby can get a lot done with fewer statements compared to C), but to me this effect is in a different category than readability.
Take the following code, which I had occasion to write this morning:
foreach (var item in items) {
if (items.Where(item2 => item.Upc == item2.Upc).Count() != 1) {
item.Duplicate = true;
}
}
This is the most readable and straightforward code I could come up with for the task; it's also not particularly efficient, since it does at least twice as many comparisons as necessary (more if there are actually duplicate items). To make it more efficient would require extra loops and manually indexing them to skip over comparisons that had already made; in this context I decided against this because the performance impact was minimal since there are other far less efficient portions of the code which would best be addressed first if the program turns out to be too slow.
Ever heard of these things called "hashes" a.k.a. "dictionaries"? They are
magical boxes for elements that are indexed by name. You build such a magical
box of seen elements while going through the checking loop and you get the
time complexity of O(n) or O(n log(n)) instead of your current O(n^2), so it
won't explode when you get more elements passing through the code.
Note that this was conceived in just a few minutes of reading your code,
deciphering syntax only remotely familiar, and figuring out what was it
supposed to do, all with cold start (I haven't written much today yet).
Something went wrong with your thought process.
First, a small correction: the if statement in my original code can actually be written as the following, which is what I had in the actual code:
if (items.Count(item2 => item.Upc == item2.Upc) != 1)
With that correction out of the way, here's the code if I used a HashSet (you suggest 'a. k. a. "dictionaries"' but that is slower and I don't need the other half of the mapping which they would provide):
var set = new HashSet<string>();
foreach (var item in items) {
if (set.Contains(item.Upc)) {
item.Duplicate = true;
} else {
set.Add(item.Upc);
}
}
To my eye, this is less readable; in addition to having twice as many lines and an extra variable, it also takes extra work to figure out what it does; whereas my version does exactly what it says: if the UPC appears more than once, it marks the item as a duplicate.
For a final comparison, here's an implementation of the extra loops and manual indexing I suggested:
for (var i = 0; i < items.Count; i++) {
for (var j = i + 1; j < items.Count; j++) {
if (items[i].Upc != items[j].Upc) continue;
items[i].Duplicate = true;
items[j].Duplicate = true;
break;
}
}
This isn't significantly longer than the HashSet-based version, but it is even faster to run (I just benchmarked it) and also doesn't use an extra object which takes memory and needs to be managed and garbage-collected later.
In conclusion, while I appreciate your suggestion for a possible alternative implementation, I do not appreciate your impugning of my abilities with the suggestion that "something went wrong with your thought process", and implying that I may not be aware of basic data structures.
Dude, you're leaving O(n^2) landmines in your code and you're now justifying
them by linecount and readability (actually more like familiarity with using
sets and mappings). You have just proved my intuition about your abilities.
Not to menion that:
> you suggest 'a. k. a. "dictionaries"' but that is slower
In what way you think mappings are different in implementation than sets that
makes them slower? They only need to carry one more pointer, and you're
already writing in a language quite detached from bare metal.
One more thing, since you decided to "correct" yourself instead of letting
the mistake slip: your "working" code is still wrong, unless something very
weird happens in the data (but then calling it more readable this way is
fundamentally wrong).
> Dude, you're leaving O(n^2) landmines in your code
O(n^2) I do not dispute. "Landmines," however, I take offense at: my naive implementation can still check 10,000 items in less than three seconds; should this ever become a bottleneck I assure you that I will adjust the implementation accordingly. Considering that hitting this number would require expanding the entire company at least tenfold, and knowing how other portions of the code work, I feel justified in saying that this is likely to be the least of their problems.
> you're now justifying them by linecount and readability (actually more like familiarity with using sets and mappings).
The entire point of this thread was justifying by readability, so yes, I am. I'm well familiar with sets and mappings, I just don't think that they're the best solution for this particular task.
> In what way you think mappings are different in implementation than sets that makes them slower?
I don't know the internal implementation details, but having just benchmarked it I can tell you that Dictionary<string, Item> is roughly 8% slower than HashSet<string> for two otherwise identical implementations of this method.
> You have just proved my intuition about your abilities.
Likewise. From the preceding conversation, I conclude that you are inclined to prematurely optimize at the cost of maintainability and that you tend to look down on and make fun of anyone who you believe knows less about a topic than you, without taking the time to consider their point of view, or even basic politeness. You may not think that this description accurately depicts you; but then I don't think your opinion of me seems to be correct either.
Considering that I have now spent far more time than this code will ever run for arguing the point, I'm going to step away from this discussion now. I feel that I have made my point; increasingly heated argument seems unlikely to affect the outcome of the debate.
> O(n^2) I do not dispute. "Landmines," however, I take offense at: my naive implementation can still check 10,000 items in less than three seconds
If you're satisfied that the loop you presented runs for a time comparable
with three seconds for merely 10000 elements, it says plenty enough about your
craft.
> [...] I can tell you that Dictionary<string, Item> is roughly 8% slower than HashSet<string> for two otherwise identical implementations of this method.
Ah yes, benchmark comparing non-implementation (abstract class) with an
implementation (concrete class).
> From the preceding conversation, I conclude that you are inclined to prematurely optimize at the cost of maintainability
No. I just tend not to leave behind ridiculous algorithms, especially when an
acceptably efficient solution is of comparable code complexity.
> [...] You may not think that this description accurately depicts you; but then I don't think your opinion of me seems to be correct either.
Parts of it, yes, they do match. I'm an asshole that laughs openly whenever
sees statements that look ridiculous made by somebody who considers themselves
an expert (note that it doesn't matter whether they are or are not actually an
expert). But then, it's not my code that takes three seconds to walk through
ten thousands elements when -- as napkin calculations show -- it should take
under a millisecond.
> More readable code almost always means less efficient code.
Incorrect. Most practices like meaningful variable names, logically separated functions and classes, comments where appropriate, etc have absolutely no impact on performance. Principles like DRY and KISS and YAGNI typically also lead to better performance. Only in rare isolated cases might there be a conflict, eg. where a more cryptic algorithm have better performance than the straightforward.
Planning for extending the code is the wrong way to think about it. To many that means overgeneralized code, which is a terrible.
The right way is to write modular code, where each class/function has simple and clear responsibilities. In that kind of code, changes are usually isolated and clear.
You're good at programming if you work hard at really learning your craft.... learning some things to deep expert level and many things to competence. So many programmers make no determined effort to learn - they are the shit programmers.
I'm not a fast programmer nor the smartest, but I am a relentless problem solver. I'm the terminator of problem solving ..... once I get stuck into working something out I just can't rest till I've cracked the case.
Even though by OP's criteria I am a good programmer, I still think I am terrible compares to my manager. I want to step up. Currently at a web based startup. What can I do to become better in terms of knowledge?
Someone has to give the obvious (possibly wrong) answer, and it might as well be me. If you've already identified someone who you think is better than you, why not ask how they do it?
If you're asking about intrinsic ability, don't worry about it. Nobody is born with the ability to program, it's all a matter of time invested. You need an interest and passion, time will do the rest.
It's too broad a question to give a definitive answer to. It depends on the context.
If you want to generalize, follow the 80/20 rule - 20% of the effort results in 80% of the benefit. Think like a business owner. Identify what the one or two key metrics are and come up with ways to efficiently ship ideas to test to improve them. Write code that is easy to test. Add high value tests. Avoid perfectionism.
What's wrong with, you know, write correct code that is maintainable and testable?
I've observed that especially correctness is the main line that separates a master programmer from a mediocre one.
If you are constantly making errors and not testing properly, not checking the integrity of your data, etc. You are just mediocre and are probably being held at your position against your will.
If you deep dive into any subject head first, all in, you tend to get pretty decent at it but you have to have passion and grit to do that and not everyone does. There are some people with exceptional intellect but those types are very rare so being good is achievable for most of us but being Elon or Carmack or Hassabis isn't.
I think it’s consistently choosing the harder more correct path. You know you need to refactor a piece here or name a variable consistently there, but I’m tired, I’ll just slack off this one time... unfortunately, as I’ve proven a few times, compound interest is a bitch.
"Programming" is easy. You pick a language, learn a set of rules, and over time learn how to tell the machine what you want it to do in that language fairly well.
Software development is hard. Unlike many other building tasks that humans run into, software is rarely "done". Launch of software for most of us means the code we've written has just been promoted to a point where now it's important, and will likely be what we work on for the near term future.
So, what makes a good software developer? Generally, programming's the smallest part of that puzzle. Working effectively with others ranks up there. Business acumen. Communication skills, both written and verbally. Understanding release cycles, revision methods, standards, etc. All the things that developers don't want to care about because they aren't writing code, those are the things that make good software developers.
That is a bold statement. All the things you list are true, but it also depends on what you are doing. For most Web/Mobile/Enterprise apps you are probably right. But then there are also some areas like graphics programming or AI were the algorithms can absolutely be the hard part.
I consider myself fairly good in my domain (Fullstack but mostly backend) but when i see what some people in graphics programming (or Games in general) or AI are doing, i feel like a newbie. In my domain, i rarely have to deal with complex math, it's more about writing readable, clean and well tested code that is well designed in terms of architecture. But in some other areas you actually regularly have to face pretty complex problems where the stuff i just listed kind of becomes the easy part.
Even with the algorithmic challenges, games and graphics, and most AI at the moment is short lived and in my opinion easier, because you can deprecate things quicker. A lot of the foundations of what your building on in those fields is rapidly changing and many of the products are built for a single purpose. That makes things easier because you can escape bad choices quickly.
On the other hand if you're building a service for a business, like an auth layer or a payment system, the mistakes you make will live on and on and on. And usually you only get one shot at creation before it's in support for a very long time.
But to be a good at programming/developer. I would say know enough too know what questions to ask and make sure you talk with people on the client side often. Focus on whats important to them, and get change management and security onside before going near prod.
Do we need to remember the distinction between type I and type II programmers? it sounds like we do. what you described are the type II variant. (and there are a lot more of them).
type I = kernels, database query engine/optimizers, compiler internals.
type II = glue libraries together with a high level language to solve business goals. type II often rely on type I's work.
I don't agree with that distinction. The programming part of it is still easy - even easier, I should imagine, for what you're calling the type I programmers.
The only difference is, the type I's "business" is algorithms and optimizations instead of yet another CRM or crunching some sales data. The underlying science behind what they are doing with it is difficult - just like dealing with business problems are, and most of them will succeed or fail in their efforts for the same reasons - ability to communicate and work with others.
> "Programming" is easy. You pick a language, learn a set of rules, and over time learn how to tell the machine what you want it to do in that language fairly well.
Chess is easy. You get the chess board, learn a set of rules, and over time learn how to pick the right piece to play the game fairly well.
Being good at chess/programming would be totally different from knowing "whats happening programming/chess".
If you want to use analogies, then winning at chess would be akin to developing software, which is the same distinction I made. Learning the rules of 6 pieces vs strategically using those rules to win are different things all together.
One moment he says he asks a candidate to program something he could never have foreseen, another moment he says the candidate should have been planning for it.
What.
There is one rule I try to go back to, especially when work starts to pile up and things fall by the wayside. YAGNI.
I think the question "how do I know if I'm good at programming?" is a non-helpful question if the ultimate goal is introspection or diagnosing professional development. Any mentor who hears such a question should absolutely take the time to get the asker to pull back and re-think what they're really asking, rather than dive-in and start giving specific pseudo-objective advice about "code".
First, it is far too broad. What does "good" mean? Good enough? The opposite of bad? Compared to whom? And even "programming" is a ridiculously vague thing-- everyone who has worked even a year in the SW development profession will know that programming is only part of the job and that there are many different roles, many different kinds of skills.
Next, what is the intent of even asking that question? What can one do with "the answer"?
1) You ship stuff often. Programming isn't useful unless someone besides you benefits.
2) The code you put into production is stable and doesn't require a lot of operational work (bugs)
3) Other people can understand your code easily and modify it when needed, without requiring long explanations from you
4) You can work with other programmers and use best practices they recognize, and you are also good at teaching these things
> Programming isn't useful unless someone besides you benefits.
I beg to differ. I did http://loup-vaillant.fr/projects/ussm/ only for myself. Its release, documentation, and the few external users multiplied its usefulness accordingly, but even if I didn't release it, it would still be useful.
hey guys I was introduced to emrysghosthacker@gmail.com because i really wanted to know what my husband has been up to lately as I seem not to be getting his attention.
Emrys was able to hack into my husband’s Facebook, Snapchat, WhatsApp, Instagram and above all gave me full access to his mobile phone and emails without touching the phone. I couldn't help but to introduce him to those who have their spouse cheating on them and want to spy on them. contact emrysghosthacker@gmail.com or wechat at emryshelp he will help you out with any hacking related issues, tell him rhonda referred you..thank me later.you can also contact him-+14088189369
The best advice on the profession that I was ever given was simply, "Learn to learn."
The vast majority of this profession is just being interested in figuring out how to solve different problems. Sometimes that means it's all you and sometimes it means learning new things or doing research.
You know that you are not a good programmer when you don't see any problems that need to be solved.