As a trainer at click solutions, I regularly supervise trainees and students. Through appropriate onboarding and the teaching of technical content ...
For further actions, you may consider blocking this person and/or reporting abuse
Let's add one more: good developers can explain the code they create to people who are not developers themselves.
I might take that one step further.
Good developers write their code and document it specifically for the "next guy".
So that they don't have to explain it in person.
Thanks for this @beernutz . It is something I really struggle with and would like some guidance.
How do you this easily? Do you document via comments or using an external application (like Notion, Google Docs etc).
Will appreciate your insights.
It depends on the context. Most often I try to keep the explanation as close to the code as possible, so a docblock at the top of a method, or an inline comment block right next to some code that seems clear what it is doing, but maybe not the REASON for it being there.
This can help a lot later too, when it comes time to refactor. For example, you might have some code that is used to work around some odd bug in an API or something. That is a great place to comment about WHY it is there, and when you might be able to retire it. I do this a lot when I have to work around bugs in other systems I am integrating with but don't have code access to.
All that said, I do keep a pretty extensive evernote collection. This is most useful when hunting down weird bugs or issues, as you can quickly outline what the problem was and the steps you took while investigating and fixing.
These have BOTH saved my bacon numerous times, and I highly recommend getting in the habbit of doing both.
I stick with Evernote because it is synced everywhere, and can be quickly pulled up and saved. Though there is one caveat there: The latest version (10.x) is significantly worse than the 6.25.x line. They moved to an electron type app and lost all the global hotkeys and direct note linking and such.
@Ekanem, On Pull Requests!
Following this template here in our company(skore.io):
What?
Change something...
Why?
Because...
Link to the card/ticket.
I appreciate your detailed feedback
And great developer produces code which is self-documented, so he spares time with "document the code" step.
That is great when you can do it, but there are a lot of places (domain knowledge for instance) where documenting WHY this code exists is important I think. That and in general it feels like we should be documenting the "why" instead of the "what" if that makes sense.
Agreed.
That would be a great developer, a good one could explain their code to a rubber duck.
I think rubber duck debugging is a different thing. Generally you explain your code to the "rubber ducky" to help you find a problem you are looking to fix. There is something about doing that that really does help, and if you don't have to bother someone else, you can save time and use less human time. 8)
Pardon me if i explained something different than you meant. Just thought that concept deserved some more info.
Yes it is a different concept, originally I was going to say "explain to another developer" but decide to take it to the debugging idea.
This is so true.
Interesting thought, Thomas! 🤔
True when you are capable of doing that then you reach the level of Sensei. 🧘
I would also add, knowing when to NOT write code to try to solve a problem.
As people trained to, and love to, solve problems with technology: its easy to forget that a new, or modified piece of software may not be the best tool to solve the problem.
Often in my career I've come across problems that the business clients have thought needed to be solved with a new software tool. However after some real analysis, the root problem was a business process problem or people problem. Often these are solved by a) removing legacy business processes that no longer served a purpose (It's how we've always done it), training people on the correct way to do things, or often simply having people talk to each other.
Any bit of code that is NOT written is another bit of code that doesn't need maintenance, doesn't incur technical debt, and doesn't hide implementation (and eventually becomes part of the organizational magic.)
I'm often asked to help automate business processes. The clients bring a flow diagram many feet across describing the process they currently follow. They usually believe they need to automate it exactly as it is. My first job is to help them walk through and evaluate the utility of each box, line, and all other items in the process. We can usually, after a few rounds, cut out about 1/4 to 1/2 of the process as followed while maintaining the same utility, well before any code has been written.
Valid point but I think that is really high level and something for a great developer. We still need room for improvement. 😉
Also: a good developer has internalized that it's not about code.
The root cause of that task on the kanban board is to solve someone's problem, or allow a person to do more than before; even though that one task may seem to be all about coding, the deeper motivation for the task has nothing to do with code. If there was an easy way to achieve the same core thing without code we'd likely do that instead.
When on the clock, we're coding as a way to get to that end, not to play with our toolchains.
It's a kind of eyes-on-the-prize mentality that's an essential part of being a good dev imo.
</10c>
Like that point very much!
Great article, I would add some Clean Code issues that fit here too, it is great to apply the KISS and DRY principles but you have to take great care in the details, produce readable and elegant code.
To me a great professional developer (I think "professional" is the appreciation that might be missing here) loves what he/she does, tries to come up with a solution differently if necessary and is empathetic enough to think about other developers and users when writing code.
This really covers almost everything you need to be a great developer. The never stop learning and want to be better are probably the most important things. Anyone with those two qualities will eventually get the other things and become an excellent developer.
Totally agree.
Want to add comment in the communication and works in teams part, more often than not there are multiple approach/idea to solving a problem, a good developer I think is the one that willing to test those ideas by share and explain it to others.
Just to throw another acronym, has good understanding of SOLID principles.
Thanks for your feedback. Interesting point. I would say: yes and no. I think this is something a great developer should master easily. But you need some sort of experience to feel yourself certain in that field. This can be the case for a good developer, but it is not a must in my eyes.
Interesting
What makes a good developer? Besides all that has been said, I'd say passion.
Practice, practice practice makes a good developer
Great article! I'd also add: understands the impact of his/her work on the business.
Good point!
good one! Thanks
Great article. Congrats Paul!
Thanks Paco. Glad that you like it! 😊
That's very true. I love this meme!
What's so funny? 😄
Good developer write readable code.
Agreed, good developers write code with future vision.
So intresting, good job ! 🙂
Thanks! Glad that you like it. 😊