What do you believe describes a programmers skill level?
Pages: 12
| A programmer that comes to the project team leader one day before the project deadline and tells him "look, if we rewrite all those simple for loops into this multiple self-adapting hashing scheme using artificial neural network, SVMs and butterfly swarm optimisation I've just found in this article, we can get a 30% performance improvement!", is *not* a skilled programmer. |
| A programmers skill can also be based upon their ability to focus on the end-user. How will this person perceive my program? What are the possible errant pieces of information that could be inputted and how do I check and correct this problem? When someone can write efficient code that caters to their end user and has that sort of focus to be fully aware of them, then I think they are one step up on the ladder. But as has been said, it is such an ambiguous concept with so many aspects and truthfully an infinite number of levels that it is hard to concretely define. |
I agree totally. Our programmer objective is to produce programs that automates and make life easier for our users. If a well-polished and well-performing program does not get the usage of users, then it is just a good effort for self-actualization needs.
For this I would include a good programmer skills to include the non-technical aspects of it. The ability to put yourself in the shoes of the user and see if what this program offers is what you will want to use. This is a pretty subjective matter but some percentage of time allocated in this area will greatly enhance the skills level of a programmer. The ability to identify with the users so you can write your program tuned in their expectations so that the final program deliverables they can use them.
My self-actualization needs is to see customer satisfaction in using my final output to make their life easier. This is what drives me to continue software development. Of cuz the pay-check is one deciding factor as programmers like all other profession still need them to feed family, eat, shIt, sleep etc too :P
I can't tell if the problem is that it's one day before the deadline (it could be left as a todo for 2.0) or that it's an overly complex solution (a 30% improvement could matter a lot). Without more context, it's not necessarily an obviously bad suggestion, if the thing actually works. |
Both. Even if it is left as a todo for 2.0, thinking abut overly complex solutions with arguable benefits one day before the deadline is a bad sign. And getting 30% improvement almost never matters (unless customer really demands it, but I have never met a client that wanted performance to be top priority, even in gaming industry), if it is achieved by something overly complex, that will take half a year to implement and one year to stabilize and probably introduces hard-to-find bugs. By this time, the hardware will improve by much more than 30%. A good programmer needs to take into account all software quality criterions but concentrate especially on those demanded by the client.
The most successful IT companies are not the ones hiring the "most clever" programmers knowning all the algorithms, etc., but those who understand their customers the best. So therefore I think a good programmer needs to have also good social skills - e.g. understanding non-technical people or explaining things to non-technical people.
Last edited on
It seems most ppl are taking the definition of a good programmer much higher. It now encompasses the non-programming aspects of it. To be able to relate to users, understand what they want, able to explain to non-technical users in as simple as possible are factors that contribute to the traits of a good programmer.
Unfortunately, some programmers prefer to code than to talk to users. I guess this is why they are unable to break free from their daily routine. There lies the opportunity for positions like project manager, business analyst etc to fill that void. If a programmer can elevate themselves to also undertake those tasks ON TOP of doing programming, it is a win-win situation for the employer.
That is also why it is often said once you get older, you do less programming but more on managing your users expectation. Personally for me, I very much prefer to do programming but I wise up 5 years ago when a pep talk by a end user wake me up. If I cannot reach out to them and understand what they want, then all the programs I have written are wasted.
Sometimes it is also because the 'middle-man' say project manager forbid programmer from talking to users that led to this cycle. Programmers program based on project manager instructions. They do not have a chance to relate to what users want. They build based on what the project manager want which presumably is what end users want. This setup can cause a lot of unhappiness between users,project managers,programmers. Arguably it should be users -> programmers cuz the output users get is from programmers. They only tell what they want to the project manager who may not be the one doing the implementation.
I guess one learns as one ages older.
Unfortunately, some programmers prefer to code than to talk to users. I guess this is why they are unable to break free from their daily routine. There lies the opportunity for positions like project manager, business analyst etc to fill that void. If a programmer can elevate themselves to also undertake those tasks ON TOP of doing programming, it is a win-win situation for the employer.
That is also why it is often said once you get older, you do less programming but more on managing your users expectation. Personally for me, I very much prefer to do programming but I wise up 5 years ago when a pep talk by a end user wake me up. If I cannot reach out to them and understand what they want, then all the programs I have written are wasted.
Sometimes it is also because the 'middle-man' say project manager forbid programmer from talking to users that led to this cycle. Programmers program based on project manager instructions. They do not have a chance to relate to what users want. They build based on what the project manager want which presumably is what end users want. This setup can cause a lot of unhappiness between users,project managers,programmers. Arguably it should be users -> programmers cuz the output users get is from programmers. They only tell what they want to the project manager who may not be the one doing the implementation.
I guess one learns as one ages older.
| By this time, the hardware will improve by much more than 30%. |
| if it is achieved by something overly complex, that will take half a year to implement and one year to stabilize |
| thinking abut overly complex solutions with arguable benefits one day before the deadline is a bad sign |
| Nah. That's what the leader is for, to decide which things are worth doing and which aren't, since he has the advantage of perspective. |
If the leader made the bad decision, will he shoulder the responsibility or push the blame to the programmers incapability to implement the grand algorithm the leader has visualized?
I have been in such countless situations when the leader claim my incompetent implementation lead to his grand algorithm unable to realize it's performance benefits. He is saying the algorithm is flawless if executed correctly. So he is hinting he is not at fault and the fault lies in my incompetent implementation.
If the leader volunteer to do the implementation besides just offering the grand algorithm, then if anything goes wrong, he has no way to escape from any blame. But most of them are smart, they leave a 'life-line' for themselves for worst case scenario.
Now it seems going higher in the career ladder ensures you have some edge over your lower rank subordinates. Strange but true!
That's a rather weak argument against optimization. 1.3*x>x |
Above some performance level, there is always no difference. It doesn't matter if my game runs 60 FPS or 90 FPS, when my monitor can display only 60 FPS. It doesn't matter if I have to wait 0.05 s after clicking a button or 0.03 s. But anyway, that was just an example, don't treat it so literally. A good programmer needs to have some wider perspective, not just "solve the problem with as fast code as possible". And the team leader often doesn't have enough time to keep an eye on everything.
sohguanh: What are you getting at?
You first have to get to the level beyond which there's no difference. It would be a mistake to think you're always at that point.
A game is possibly the worst example to use against optimization. Even if you don't see improvement in one configuration, there's always a whole bunch of other, slower configurations that will see an improvement.
"There is always no x" is such an odd construction, by the way.
I did say that a 30% improvement may matter, rather than always matter.
At the very least, he can tell the programmer who just came to ask about some weird optimization technique not to unravel the program into a horrible mess, or to do it in a branch of its own.
| Above some performance level, there is always no difference. It doesn't matter if my game runs 60 FPS or 90 FPS, when my monitor can display only 60 FPS. |
A game is possibly the worst example to use against optimization. Even if you don't see improvement in one configuration, there's always a whole bunch of other, slower configurations that will see an improvement.
"There is always no x" is such an odd construction, by the way.
| But anyway, that was just an example, don't treat it so literally. A good programmer needs to have some wider perspective, not just "solve the problem with as fast code as possible". |
| And the team leader often doesn't have enough time to keep an eye on everything. |
I think sohguanh was getting at:
http://www.geeksaresexy.net/wp-content/uploads/2009/07/howitis.jpg
The corporate hierarchy pyramid: "when you look down, all you see is sh**, when you look up, all you see is a**holes ".
http://www.geeksaresexy.net/wp-content/uploads/2009/07/howitis.jpg
The corporate hierarchy pyramid: "when you look down, all you see is sh**, when you look up, all you see is a**holes ".
| And the team leader often doesn't have enough time to keep an eye on everything. |
Then they aren't a very good Team Leader are they? If they are so bad at delegating the work load that they can't even pull off middle managment then they need to be reevaluated for their position. I know that a lot of management types are control freaks but that does not mean that it is a good skill for the job.
| The corporate hierarchy pyramid: "when you look down, all you see is sh**, when you look up, all you see is a**holes ". |
How true indeed! So it seems the a**holes passed down all the sh** for the lower rank workers to clean up isn't it? How convenient! No wonder everyone is aiming to be up above in the corporate hierarchy! Then slowly the whole corporation will then collapse cuz everyone is squeezing to the top but the bottom has nobody. :)
Topic archived. No new replies allowed.
Pages: 12