Ask HN: Do you consider yourself to be a good programmer?
if not, why? how do you validate your achievements?
The root cause of this, I think, is that I just don't like programming that much. I'm a smart person and I think I could be an above average programmer if I applied myself but I just don't care enough to do so. There are other things that I enjoy more that I want to spend my time and effort on.
I thought that this would be a problem when I graduated but it turns out that the world needs average programmers. My current project at work is a Windows Forms app written in C# to pull data out of a database and plug it into a Word template to generate a Word document. It's not glamorous and it's not trendy but it needs to be done by someone. Pay me a decent salary, give me good insurance, and I'll gladly clock 40 hours a week writing CRUD apps because it beats manual labor, retail, or going back to school.
I think if you care about what you do, then you're probably already in the upper 50%, because most people don't, and it shows. Now if you pair giving a fuck with some programming talent and interest in improving your skills and productivity you can easily get into the top 10%.
To get into the top 1% you need to be very focused on programming. I have too many other hobbies to be that focused only on this aspect of my life. But I'm ok with that.
If you start comparing yourself to internet people, there are just too many that you can compete with them on everything. There are too many experts in too many niches that you could read all the HN articles and compare favorably in comparison.
I feel no need to validate my achievements.
(This is a little bit trollish, forgive me.) You could use a matrix of pots, pans and knife work as a proxy for a chefs competency I suppose. Or, you know, you could taste the food he creates.
> - http://sijinjoseph.com/programmer-competency-matrix/
> - https://competency-checklist.appspot.com/
> - https://github.com/hltbra/programmer-competency-checklist
If you're not familiar with TDD, you haven't yet achieved that level of mastery.
There's a productivity boost to being able to change quickly without breaking things.
Is all unit/functional/integration testing and continuous integrating TDD? Is it still TDD if you write the tests after you write the function (and before you commit/merge)?
I think this competency matrix is a helpful resource. And I think that learning TDD is an important thing for a good programmer.
And a good programmer asks why people might have spent so much time formalizing project development methodologies. "What sorts of product (team) failures are we dealing with here?" is an expensive question to answer as a team.
By applying tenets of Named agile software development methodologies, teams and managers can feel like they're discussing past and current experiences/successes/failures with comparable implementations of approaches that were or are appropriate for different contexts.
To argue the other side, just cherry picking from different methodologies is creating a new methodology, which requires time to justify basically what we already have terms for on the wall over here.
"We just pop tasks off the queue however" is really convenient for devs but can be kept cohesive by defining sensible queues: [kanban] board columns can indicate task/issue/card states and primacy, [sprint] milestone planning meetings can yield complexity 'points' estimates for completable tasks and their subtasks. With team velocity (points/time), a manager can try to appropriately schedule optimal paths of tasks (that meet the SMART criteria (specific, measurable, achievable, relevant, and Time-bound)); instead of fretting with the team over adjusting dates on a Gantt chart (task dependency graph) deadline, the team can
What about your testing approach makes it 'NOT TDD'?
How long should the pre-release static analysis and dynamic analyses take in my fancy DevOps CI TDD with optional CD? Can we release or deploy right now? Why or why not?
'We can't release today because we spent too much time arguing about quotes like "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." ("Self Reliance" 1841. Emerson) and we didn't spec out the roof trusses ahead of time because we're continually developing a new meeting format, so we didn't get to that, or testing the new thing, yet.'
A good programmer can answer the three questions in a regular meeting at any time, really:
> 1. What have you completed since the last meeting?
> 2. What do you plan to complete by the next meeting?
> 3. What is getting in your way?
And:
Can we justify refactoring right now for greater efficiency or additional functionality?
I find blackbox testing itself also fairly useful. The part where you forget which parameter combinations may occur can be useful since you now A) rely on documentation you made and B) can write your test independent of how you implemented it just like if you had written it beforehand. (Just don't forget to avoid falling into the 'write test to pass function' trap)
It's also easier to adversarially write tests with a fresh perspective.
I shouldn't need to fuzz every parameter for every commit. Certainly for releases.
"Building an AppSec Pipeline: Keeping your program, and your life, sane" https://www.owasp.org/index.php/OWASP_AppSec_Pipeline
The general solution is to use whatever testing methodology you are comfortable, that is very effective, very efficient and covers a lot of problem space. Of course no testing method does that so you'll have to constantly balance whatever works best (which is why I think pure TDD is overrated)
No. They differentiate in the matrix.
> If you're not familiar with TDD, you haven't yet achieved that level of mastery.
That's not true - I've worked on teams with far lower defect rates than the typical TDD team.
TDD can help keep a developer focused - and this can help overall productivity rates - but it doesn't directly help lower defect rates.
We would need to reference some data with statistical power; though randomization and control are infeasible: no two teams are the same, no two projects are the same, no two objective evaluations of different apps' teams' defect rates are an apples to apples comparison.
Maybe it's the coverage expectation: do not add code that is not run by at least one test.
I've looked into TDD but it simply does not fit my way of thinking and how I approach problems. I prefer to test systems when I have finished them as I cannot formulate a test before I know what I'm testing.
Especially for organically dogfood-development TDD is a bad methodology as you discover requirements as you go.
TDD is however great if you have requirements before you start writing any code (aka Waterfall but swap Testing and Coding)
No, there can never be irrefutable, objective proof for something that is a best practice. What you can do is check which teams are having the most bugs found by the customer, or how long they need to deliver that code, and then draw some statistical conclusions from it.
In my (subjective) experience TDD a) gives you really good regression tests and b) makes you create smaller functions that are more easily testable and c) makes people think harder about their code.
b) and c) aren't really effects on the tests, but because TDD drives this behavior (again, subjective experience) you get a better codebase, which in itself is of value.
If you can get to that great codebase without TDD and write good regression tests catching all the edge cases post hoc, then you don't need TDD.
>Especially for organically dogfood-development TDD is a bad methodology as you discover requirements as you go.
Especially in this case I find TDD very helpful, because it provides a kind of executable documentation of the requirements you just discovered you want.
That's rather begging the question, isn't it? There cannot be proof for the one true way since it's the one true way (or as you call it, best practise)
>In my (subjective) experience TDD a) gives you really good regression tests and b) makes you create smaller functions that are more easily testable and c) makes people think harder about their code.
In my experience, only when those people tended to do that beforehand. And b) and c) don't hold true in my experience either (people are happy to write big functions so their tests pass).
c) is IMO not true either since it feels more like writing code to make tests pass not making code that fits requirements (unless you're good at writing requirements into tests but then why write code to tests code if you could write the code directly?)
>Especially in this case I find TDD very helpful, because it provides a kind of executable documentation of the requirements you just discovered you want.
That's not how that works. I'm sitting in the middle of a function, discovering requirements for that function while I'm writing it and running the application (ie, function does X but also should send an event to Y to clear the cache for user Z who triggered action X)
When you don't have any fixed requirements, applications tend to evolve in-vitro, which doesn't mix well with TDD which is an pre-vitro.
Not even close.
Ever heard of Jeff Dean, Linus? Carmack? Norvig? Then when I look at the multitudes of opensource projects in Github, I can only stay humble. I'm average at best if that.
I don't think of myself as a "good programmer" because "good" is too blunt a qualitative measure to be productive. It's a disagreeable and poorly specified measurement. I haven't seriously thought about whether or not I'm a good programmer, just as I haven't thought about whether or not I'm a good person. In fact I consciously disengage from assessment like that.
I validate my achievements on a case by case basis, and I validate them according to how close I came to maximal efficiency and minimal time in accomplishing a task. It would be deceptively attractive to use those two heuristics as a rhetorical scaffolding for the meaning of "good", except that I don't compare achievements; they're mostly orthogonal.
The question of whether or not I'm "good" has no meaning for me, because I only evaluate performance within the confines of discrete tasks and sets of related tasks. Further I personally don't have enough insight into the difficulty of all possible tasks, so I refuse to generalize my performance on any particular subset of them to how well I'd do on a majority of them. And to the extent that there are only so many tasks and skills are transferrable: any given task may have differing dimensions of deadline, efficiency or implementation requirements. To get a useful measurement, you'd have to draw arbitrary lines in the sand across each of these dimensions and convince everyone else in discussion that these lines are the sensible ones.
This probably isn't a satisfying answer. But it's not intended to be. The idea of a "good programmer" is conceptually attractive but practically meaningless.
It's a question about how you view yourself, not about objectively comparing your programming skills to someone else's, therefore it doesn't require a common definition or measurement.
Therefore, the only thing anyone can conclude from responses is, "For some definition of 'good programmer' which is specific to each individual respondent, approximately x% of respondents believe they satisfy the definition." It's one thing to solicit opinions; it's another thing entirely to open the floor for opinions which may not even be the same. The OP may have received personal assessments and anecdotes about steak, apples and cauliflower when their intention was to solicit personal assessments about almonds.
edit: I think the biggest thing holding me to being average at best is practical experience in larger systems. In school, I was always good at the theory parts of computer science, but did so-so in projects. In my professional experience, I think that still holds true: I can manage language intricacies, and write pretty clean code for smaller problems, but I can get into trouble with architecture-level stuff like defining models. I also have a tendency to over-engineer solutions to complex problems.
At times it's because of laziness (didn't read up on X), at other times due to temperament (I refuse to hold on to easily googl-able information), but frequently it's because of limited working memory or lesser ability for abstract thought.
I'm aware of impostor syndrome but I'm not sure this is a case of it.
This isn't stopping me from contributing on every team I'm a part of, getting consistently good feedback, getting interviews however. I feel in general, as you can get most things done given enough or even close to too much time, then you are generally valuable.
I'm a mature student studying a computer science degree at distinction level however my overall lack of experience is obvious to me. I know how to program the way I've been taught but I don't have the experience to say whether what I'm doing is any good.
I also have no idea where to find out whether what I'm doing is right or wrong.
As in instead of solving the problem at hand I'd rather spend a week working on my own framework so that I could save 5 minutes should I have to deal with the same thing again in future although the chance of it happening is 1 in 100.