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.
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.
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.
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.
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..
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
"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.
> "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.
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.
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.
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...
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.
>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.
152 comments
[ 2.9 ms ] story [ 150 ms ] threadAlso learning from someone better than you will help you get better at least 10x more than practicing yourself.
If the problem is a common one and nobody else is able to solve it people will use your code... even if the code isn't good.
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..
Um no.. what boilerplate project provides universal data management, business logic, and performance optimization that your project needs?
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.
Computer science is a branch of mathematics and it is all about solving problems on whiteboard in front of peers.
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.
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
in general you cannot even prove, whether a program does the right thing...
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.
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.
The programmers who don't respect these principles tend to not being able to produce a code that works, so I agree with you
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.
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.
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.
Anyway, I think you need to look up the words "tirade" and "incomprehensible"
tldr: Welcome to the Internet
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.
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 feel this may be too specific to your personal experience / work history.
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.
Personally I'd choose somewhere else to work.
It seems the boss is really the problem then :)
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.
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.
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
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.
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.
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.
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 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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
[1] https://github.com/runeksvendsen/rbpcp-handler/blob/master/s...
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...
- It keeps workings
- It's not hard to explain to a new team member how
A programmer who thinks that they are bad at programming is almost certainly correct.
On a team, one of these people is more dangerous than the other. Knowing which is the greatest wisdom.
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!
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.
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.
> I know 2+2 = 4 but how do you know that how do I learn to know that!
Did you miss some punctuation?