X-post: What is a 'good' programmer?
1 21 Nov 2017 12:39 by u/IsaacJan
(Posting this here as well, would genuinely like input), this is in response to a comment I just read. "Colleges are pumping out shitty coders by the hundreds."
I'm trying to become a programmer. What exactly makes a programmer shitty? Why is it bad to get a degree with the intent to be a programmer?
What exactly do I need to do to not be a shitty programmer? I'd appreciate some answers, because broadly labeling college graduates trying to be programmers shitty is confusing me right now. What is the difference, what do I have to do to be a 'good' programmer?
24 comments
1 u/TheBookWasBetter 21 Nov 2017 22:51
Don't code to write the application, code to solve the problem.
1 u/michaelhurst 23 Nov 2017 16:17
I am a programmer and have been that since 2003.
I have mostly worked in Government or University.
I think the only way not to be a shitty programmer is to be a shitty programmer for a while. You need to just start doing it in a job. When you start, you will not be the one creating pages as the sole or main developer.
If you are never a shitty programmer you will never be able to be a good programmer. Until you crash the server or lock up a production database, cause timeouts, and frustrate a lot of end users with your shitty code, you will never learn to be a good coder.
To be good you need seat time and to be mentored, taught, and shown how to do things better. At some point, you become the one who teaches and shows others how to do it.
Even with all the seat time that I have, I am often asked to be a shitty coder in order to fix a bug without doing a deployment. Or I have to push a shitty piece of code due to a mistake in requirement gathering, or a mistake that was made a month before that would take too much time to fix. The idea being that it will work and we can still get it done. There is always a plan to go back and fix it. That just doesn't happen.
Just put in the time and after you have spent long enough, you will be better than good. You will still be asked to be a shitty programmer no matter what you do. At a certain point, you will review code, and ask your peers who wrote this piece of shit code. Then you will look at the source control and realize you wrote it a year and a half ago. You will just laugh fix it and move on.
0 u/RvBMan 21 Nov 2017 12:57
As not a programmer that works with programmers, here is my unfounded knowledge on how to be a better programmer:
Shitty programmers: - say it can't be done and leave it at that - are arrogant - are poor communicators - are irritable because they get interrupted (hint, be good at communicating when focus is necessary) - get frustrated by problems - don't know how to prioritize - don't know how to balance effort (getting it out vs doing it really well)
0 u/SpottyMatt 21 Nov 2017 14:30
Great list! But… Want to go add a space so your second list actually renders as a list?
0 u/Morbo 21 Nov 2017 16:21
You have really nailed down the essence of what makes good programmers good. Your point on spending a majority of the time on understanding the problem is key to the success of a software project. By understanding the problem, the workflow of the users and the users themselves, coding the software just becomes a mundane process where you're just writing the logical rules that translate into the work the users do. I have preached this process for many years both to programmers and the business customers alike. I always try to get the coders and users together to run through things manually or at least deeply discuss the way the work is to be done so we can capture better requirements and actually determine what is needed rather than what they think they need. My most successful projects were done this way where we met with actual users and business people to hammer it all out before one line of code was ever written. We all knew we did it right when the users understood the software without the need for training and there were no feature changes needed or logic bugs to fix. I wish Software Analyst positions were more common in today's programming world. They are the ones who would make this happen and act as the liaison between the coder and the business so that the programmers can be shielded a bit more from the customers since we all know they are not always compatible with personalities or ways of thinking. The modern software world could learn a lot from the old ways since this rapid release, Agile and "eternal beta" mentality we have today is definitely not working better than what it was meant to replace.
0 u/WhiteRonin 21 Nov 2017 17:26
Your example of talking to users and working out the flow is what agile was supposed to be.
Corporations that have a budget and goals set won't allow an eternal beta. But I do get your point.
0 u/Morbo 21 Nov 2017 17:38
My experiences with Agile were the opposite. Agile became more about the code delivery than meeting the requirements of the projects. The older JAD/RAD model worked along those same lines but with actual user involvement because they were embedded in the process. It seems that the attempts to improve on that model ended up turning it into something less effective by applying trendy new project management garbage and endless sprints, meetings and deadlines. Sometimes I think the old Waterfall method may have been closer to the ideal for how a software project should work but there are too many people who oppose it or call it a text book example of how not to run a software project. I'm afraid to see what comes after Agile has run its course. I'm sure it won't be better though.
0 u/WhiteRonin 21 Nov 2017 18:19
I just got thrown into an agile enivornment so I am still trying to get my head around it. One thing for sure, the user stories help writing tests so much easier. Meetings ... Yeah.
The problem I do see is that if a client thinks in the old way ... Yeah lots of trouble could come about.
But agile fits corporate really nicely.
0 u/roznak 23 Nov 2017 20:32
The art of working at 100% capacity and produce nothing productively.
0 u/WhiteRonin 24 Nov 2017 06:47
Which is why corporate is willing to pay more than going with a small agency ;-)
1 u/michaelhurst 23 Nov 2017 17:40
I am a programmer and most of my time is spent debugging existing issues in production as a result of a mistake made initially or a poorly thought out change request that when deployed affects other part of the application.
0 u/wrok-wrok 21 Nov 2017 13:31
Programmers who think they know everything are shit.
I'd take a Junior dev who can learn over a stubborn senior dev any day
0 u/peacegnome 21 Nov 2017 14:33
agreed 100%. I was asked to write job requirements for a programmer, and i wrote some basic ones, but then told the person who would do the hiring that we really just need someone who is comfortable learning new things, otherwise you get someone who has shitty habits and "knows best".
0 u/Wargasm 21 Nov 2017 13:52
This is a good question.
I would also like to know.
0 u/GoddammitMrNoodle 21 Nov 2017 13:53
The ultimate acid test here is whether the user gets what they need, which is not necessarily what they ask for. The programmer needs to understand how and why the program is being used. Otherwise all you get is a solution, as opposed to the solution. This is one of the reasons why working with offsite developers is so fraught with difficulties.
Of course often the person responsible to spec the project is not the same one doing the coding. So its that person's job to make sure the programmer(s) get's it, and likewise its the programmer's job to make sure he gets it.
Proficiency with the language/platform whatever is a given. As is the ability to translate a real world problem into the world of their toolset.
0 u/WhiteRonin 21 Nov 2017 17:27
Sounds like a middle missing problem. Having a solid team lead to wok on-site and with off-site helps.
0 u/SpottyMatt 21 Nov 2017 14:57
RvBMan nailed it, IMO; live by that creed and everybody will be clamoring to hire you.
As as software engineer, here's my more-specific take.
Glossary
Programmer, coder, developer, software engineer , there are lots of words to describe people that work in this field. while many different sources describe many different definitions to them, here is a set of definitions and analogies that I find useful: think of building a house.
Programmer / Coder
Like the electrician, plumber, or people laying concrete: they are familiar with how one particular media (programming language) works, and good at following instructions to build a thing with that medium.
But if you ask them to step outside the medium (e.g asked a plumber to lay the concrete for the foundation of the house), they will be stumped. Similarly, if you ask them to figure out where and how their medium should be used in the house (e.g. Ask a coder to design a whole program), you may not end up with the best thing.
A bad programmer cares only about meeting the requirements they were given (or maybe doesn't even care). A good programmer cares enough (and is familiar enough with things outside their area of expertise) to understand where their part fits in the whole and is proud to deliver a quality piece.
A lot of pain and frustration of the software industry comes from hiring coders at a coder's salary and expecting software engineer behavior.
Software Engineer
Like the civil engineers involved in larger construction projects, the software engineer is familiar enough with a wide array of tools, materials (programming languages) and techniques (design patterns), along with a wide array of problems in the space. This enables them to figure out an optimal solution to a given problem.
If you ask a ruby programmer to build you a solution, they may ask you what the ruby program should do, and then you're going to get a ruby program. If you ask a software engineer to build you a solution, they should ask you what you actually need, and you'll end up with a solution that most closely fits what you were able to communicate you needed.
A bad software engineer is usually a programmer that never learned the following:
This is like a repair shop car mechanic trying to design an engine- they know what engines are and how they work and where they go, and they think that is all that matters. But without thermodynamics and fluid dynamics and aerodynamics and materials engineering knowledge to back up all the internal components, they will really just be guessing with every choice they make and it won't be a good engine.
Architect
This word is used in the software realm, too. These people do too main things:
Bad architects design silly solutions that good engineers will immediately identify as such.
Good architects design solutions that good engineers are enthusiastic about starting on.
0 u/Deku_Knight 21 Nov 2017 17:42
Wow, thank you so much for posting this! I am still finishing school and just started working as an electronics technician because I wanted to finally get into anything that was more skill-based work.
Can you tell us of any books or courses that have been particularly influencial to you when it comes to implementing solutions?
0 u/SpottyMatt 24 Nov 2017 17:45
Sorry, not really... There was no magic in gaining the aptitude that I was aware of.
However, if you have the aptitude for solving problems, these books will expose you to many different types of problems that may lead to a better ability to recognize situations in which their solutions can be applied:
Yes, those are three textbooks from my time in college. Trying to go through them on your own and extract something useful might be considered "hard mode."
They dive deep into the problems that need to be solved in order for computers to work and are things that most people who just program nowadays will never have to think about thanks to all the work done by those people back then.
And though I don't have a book recommendation, I would say "Git Gud" at linear algebra: there are an astonishing amount of fundamental revelations in that field, and it is very heavily relied on by programs that have to deal with objects in 3D space, such as games and modeling software.
0 u/aaronC 21 Nov 2017 15:40
A good programmer is one who can use advanced algorithms and know when to apply them, while making code readable. Getting things to work is easy, specially in an age where you can get the answer to a lot of programming problems on stack overflow. You can do a lot with for/while loops and if/else statements, but there's almost always far better ways of doing things. I've had situations where I was using libraries and built in functions in PHP, I researched how they worked, and found out I could do it massively faster if I wrote my own stuff.
Bad programmers think everything is about the language, good programmers just view languages as a tool to implement algorithms that get computers to do what you want.
0 u/Sosacms 21 Nov 2017 15:44
As an employee, code what you're being paid to code. Don't coffee what you think would be better. Have a friend who can't keep a job for more than a few months because he won't give up on what he thinks would be the better way to do things... To make it worse he's often wrong...
0 u/Dark_Shroud 22 Nov 2017 08:32
So he's Rust user...
0 u/natehigger44 10 Dec 2017 20:46
Everyone will tell you something different and 90% of them will be wrong (Sturgeon's Law), possibly including me.
0 u/Tatsuya007 03 Feb 2018 05:52
This article has helped me a lot, from work, cho acc cf study and entertainment. Thanks