[–] RvBMan 0 points 13 points (+13|-0) ago  (edited ago)

As not a programmer that works with programmers, here is my unfounded knowledge on how to be a better programmer:

  • learn good logic, not just syntax
  • use the right tool for the job
  • keep code readable and simple, if it's needlessly fancy, it's "lion-tamer" code
  • spend the majority of the time defining the problem and planning the solution, writing the code is the small part
  • don't get stuck in the past or the future, things are changing but some solutions still remain viable
  • get outside of the software industry and solve problems elsewhere. A tradesman doesn't care or know about programming, and just needs a solution - working with non-programmers and solving their issues will help with communication and thinking
  • know how to research problems online rapidly

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)

[–] Morbo 0 points 4 points (+4|-0) ago 

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.

[–] WhiteRonin 0 points 2 points (+2|-0) ago 

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.

[–] michaelhurst 0 points 1 points (+1|-0) ago 

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.

[–] SpottyMatt 0 points 2 points (+2|-0) ago  (edited ago)

Great list! I love how none of it is specific to actual programming, but it's still spot on! But… Want to go add a space so your second list actually renders as a list?

[–] wrok-wrok 0 points 6 points (+6|-0) ago 

Programmers who think they know everything are shit.

I'd take a Junior dev who can learn over a stubborn senior dev any day

[–] peacegnome 0 points 3 points (+3|-0) ago 

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".

[–] SpottyMatt 0 points 4 points (+4|-0) ago  (edited ago)

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:

  1. data structures and why you might use a certain one
  2. fundamentals of how operating systems and file systems are implemented
  3. fundamentals of how programming languages are implemented
  4. fundamentals of databases
  5. classic algorithms in computer science

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 two main things:

  1. Dream up problems and projects for the engineers and programmers
  2. design solutions to problems that require familiarity with and consideration of problem spaces that are traditionally wider than a single engineers' area of expertise.

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.

To Every Thing...

Large projects generally require an architect in order to come out well.

As far as who actually does the building, highly structured organizations with rigor around creating very clear and specific requirements, can probably get away with hiring a bunch of programmers to build the project.

Places with less rigor around requirements , either due to time constraints or because that's just not how they operate, or because it's a brand-new/unknown type of project, usually fare better served by staffing up with full-blooded software engineers will be able to identify and adapt to problems as they come up.

Protip

Any course that promises to "teach you PROGRAMMIMG LANGUAGE HERE" is one designed to create programmers.

[–] Deku_Knight 0 points 0 points (+0|-0) ago 

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?

[–] SpottyMatt 0 points 0 points (+0|-0) ago  (edited ago)

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:

  • operating system concepts, by Silberschatz, Galvin, Gagne
  • computer systems, a programmer's perspective by Bryant, O'Hallaron
  • Automata, Computability and Complexity: Theory and Applications by Elaine A. Rich.

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 and basic newtonian physics: there are an astonishing amount of fundamental revelations in those fields that will transform the way you think about situations and problems in the world around you. Plus they are very heavily relied on by programs that have to deal with objects in 3D space, such as games and modeling software.

Being a good programmer is not about learning to program, really: it's about learning how to identify solutions to problems that can be built with code.

[–] GoddammitMrNoodle 0 points 2 points (+2|-0) ago 

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.

[–] WhiteRonin 0 points 0 points (+0|-0) ago 

Sounds like a middle missing problem. Having a solid team lead to wok on-site and with off-site helps.

[–] michaelhurst 0 points 1 points (+1|-0) ago 

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.

[–] TheBookWasBetter 0 points 1 points (+1|-0) ago 

Don't code to write the application, code to solve the problem.

[–] Sosacms 0 points 1 points (+1|-0) ago 

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...

[–] Dark_Shroud 0 points 0 points (+0|-0) ago 

So he's Rust user...

[–] aaronC 0 points 1 points (+1|-0) ago 

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.

load more comments ▼ (2 remaining)