- It works
- It keeps workings
- It's not hard to explain to a new team member how
How do I know if I'm good at programming?
41–50 of 153 posts
Re: How do I know if I'm good at programming?
#42Earlier quoted context omitted.
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 wi…
> Have you heard about concept of code rigidity, fragility, immobility and viscosity? The programmers who don't respect these principles tend to not being able to produce a code that works, so I agree with you
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.
Re: How do I know if I'm good at programming?
#43"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 wha…
> "Programming" is easy 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 grap…
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.
Re: How do I know if I'm good at programming?
#44A programmer who thinks that they are good at programming is almost certainly mistaken.
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.
Re: How do I know if I'm good at programming?
#45If 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.
Re: How do I know if I'm good at programming?
#46>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!
Re: How do I know if I'm good at programming?
#47"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 wha…
> "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".
Re: How do I know if I'm good at programming?
#48You 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.
Re: How do I know if I'm good at programming?
#49A programmer who thinks that they are good at programming is almost certainly mistaken. 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.
What is the meaning of programming?
Re: How do I know if I'm good at programming?
#50"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 wha…
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.