[Mrzev]

I am a software dev with 10+ years, and I really dont know how to answer this. I look at other peoples code and feel envious, but they feel the same about my code too. So, when I was looking for a job, when i was asked how good of a developer i was, I really didnt know how to answer it. Being good or bad at something is relative to others. My vision can be 20:300 , but when everyone around me is blind, my vision is good. So how do you compare yourself to average? I also have high expectations, but once again thats a relative term based on a relative value... Ughhhhh.. Then there is skills in different areas... I suck at java, but i can get by. I have never written in GO , but i can learn fast... sooo? Is it a combination of experiences in areas that match yours? In a job interview is it what aligns with their current projects?

1. How do you know if your a good or bad programmer?
2. How do you know that other person is a good programmer.

 

[The Pook]

when i was asked how good of a developer i was, I really didnt know how to answer it

the answer to that question is you are a good developer, lol.

protip: if you're interviewing for a job where you would do x thing everyday if you were hired, don't say you're not good at x thing

 

[161029]

I feel like there's 3 parts to it: how good they are at designing algorithms, how proficient they are at the language or environment, and how good of a collaborator they are.

1. They're constantly thinking about things in terms of runtime complexities. There's a lot of people who will just slap together some poorly written code in terms of runtime complexity and just hand it off to you without trying to fix it. Usually people should just take some time, sit back, and unravel the problem to think of the more general sequence of operations they need to be doing. If they aren't doing this (unless it's for a really textbook case), there's a good chance they might miss very efficient approaches to tackling the problem.

2. This one just comes from experience in working with the language. I think this is far less important than 1 but there are certain optimizations or shorthands you can do to perform certain operations more efficiently. Things like list comprehensions in Python, ternary operators, bit shifting on integers for dividing or multiplying by a power of 2, using certain fill constructors instead of manually looping through to fill, etc. It's not strictly necessary but can greatly save time, increase readability, and potentially add some performance.

3. Good comments and clear communication! Unless the code you're writing is never going to be seen by anybody except yourself, other people who take up the torch down the road will probably have a hard time understanding it. We don't work in isolated vacuums and it's pretty inefficient to do so for medium to large scale codebases. It's especially useful for helping onboard people new to the language who may not be aware of some of the shorthands or optimizations a certain programming language can make (like the ones mentioned in 2).

For 1, sometimes you will accept slower runtime complexities just because even if it's efficient in terms of Big O, it might actually be slower than another algorithm with a less efficient Big O complexity in smaller inputs. There's a lot of sorting algorithms that are like this.

 

[Mrzev]

I think I also overlooked the aspect of forward thinking. So, I am looking at this code and its a mess, the database, the model, the controller, and the page all hacked together. Some cool stuff was done, but its a confusing mess that works poorly. I know the situation was, they asked for X, so he added X. They asked for Y, so he added Y. 1 Year later, its just patches on patches of stuff. What this developer lacked was asking the right questions in regards to designing for the future. How things are going to interact. What is going to be built upon.

I know i am a good programmer, my post was wondering the reasoning behind it.

 

[skupples]

sounds like every piece of propreitary system/software I've used at every corporate gig i've worked at outside of the actual tech sector.

I was just discussing this with my boss. Some of our dev managers, and specifically the development director could be (are) absolute conmen, and the organization would never know as long as the project "works". Why? Because we're not a technology entity, as much as we pretend to be. We're an insurance entity that pays people to implement replacement/automation technology. No one outside of dev knows what any of this actually is(aside from audit). The old white dudes set goals and expectations, devs try to under deliver as much as humanly possible without getting fired. AND THE CYCLE IS COMPLETE!

remember that what you do is wizardry for anyone outside of dev, even the IT bros setting up your servers, etc (like me! )

 

[Lady Fitzgerald]

Just check to see how good the error trapping is. There are a lot of programmers nowadays who skimp on error trapping (a pet peeve of mine because it usually results in inaccurate error messages).

 

[Gunderman456]

Tighter code and less bugs.

 

[Mrzev]

Just check to see how good the error trapping is. There are a lot of programmers nowadays who skimp on error trapping (a pet peeve of mine because it usually results in inaccurate error messages).

Thats why i wrap my whole program in 1 massive try catch... GOOD LUCK CRASHING NOW... just kidding... But that is a good point. Seeing someone use a try catch instead of checking if null prior, or just using a blanket try catch without any exception handling. Yeah, i would agree that would separate the good from the bad with a subtle thing.

 

[JackCY]

You can't unless you give them work and you review that work. I don't mean code on stupid paper for 10min like most interviewers do, but give them work for a month, some project, etc. to do the job and then review.
This difference between people is very easy to see at University where everyone has to do the same thing but the results vary wildly in performance, readability, bugs, reusability. Most people just do the bare minimum to pass and this for sure translates into their work ethic too.

There are people who are good at memorizing rubbish and writing memorized crap on paper and then there are other who suck at this but excel at problem solving, designing and writing fast readable code on a computer.

In the end it seems most companies are looking for coding monkeys with a knowledge of some language to implement/code, not to be programmers, developers, to solve anything, to think, nope, just code.

Error handling, for sure, the lazy ones don't bother or even realize that something could go wrong.
I've had a test image to feed a program that many people implemented, this test image was larger and more random than what most people would bother to think of... as a result two of us could process the image in around 1 second, others would take days, weeks, months or outright crash because they ran out of RAM etc.

1) you can only know where you lie on the spectrum by comparing yourself to others in different areas
2) by comparing the other person's results

Most of the optimizations mentioned are pointless unless you test performance in specific language and implementation as often the compilers nowadays are not what they used to be in 80s, 90s and do a lot of optimizations on their own and your "clever" optimizations may actually work against it and make less readable/understandable code. Divide by 2 using bit shifting? Why? What compiler does not optimize this for you to the same fastest code?

 

[Mrzev]

There are people who are good at memorizing rubbish and writing memorized crap on paper and then there are other who suck at this but excel at problem solving, designing and writing fast readable code on a computer.

In the end it seems most companies are looking for coding monkeys with a knowledge of some language to implement/code, not to be programmers, developers, to solve anything, to think, nope, just code.

My first job as a software dev my mind blanked out one day and i forgot what a while loop was called or something basic like that. I was describing it to one of the other newer developers and he said to just use GoTo. Even I knew that was wrong... needless to say, he wasn't there for long. Managers and software architects were telling me that he interviewed amazingly, and they were surprised too. From my experience at this new job, i am afraid to work for a new group that has never done software dev before.



While driving home today i came to the realization of the difference between a Entry level, Standard, and Sr Developer.

You can rely on a Sr Developer to get whatever done with a good design.
A standard developer on their own can get it done, but with an unknown quality of design.
Entry level you cant trust to get the thing done at all.

I guess its hard to tell because a single Sr Dev in the group can give direction to Entry level so that they can get the thing done, and the standard dev will end up with a good design. 2 Sr Devs will end up with a great design.

The nonsense i am dealing with at my job its clear that the original dev is above entry level because the project works... but its very obvious that he is not a Sr Dev because of how bad the design is. He knows its bad, but he never had the time to fix it. IMO a Sr Dev would never ended up with the terrible design because we know what questions to ask and how to approach unknowns... or that you take the time to refactor it then and not skip it trying to get more work done.