21–30 of 100 posts
A lot of this is common sense stuff, but it might be better to replace this part with "Write tests." TDD is the kind of thing that sounds great in a blog post, but doesn't actually seem to work in the real world. At the very least, TDD is not a benchmark of a "mature software developer."
Sorry, but this is a bunch of bullshit. Here is the market truth: 1) know very latest tech 2) know algos very well 3) have hot brands as past work places
As it is now, your post looks like chapter list in a generic "Learn SW dev in 24 hours" book.
Sorry, but this is a bunch of bullshit. Here is the market truth: 1) know very latest tech 2) know algos very well 3) have hot brands as past work places
I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…
The solution is to ignore these "my thing is objectively better than yours in 100% of cases" debates - choose the pattern/design/paradigm/thing with the least compromises and do something productive :-)
I may be wrong tho.
> Focus on the business problem, not the code Staffing and code maintenance are business problems. The tech matters at various levels of concern.
The code can have the least amount of technical debt, be written in the most simplistic way and be abstracted enough to allow the business to evolve but if the business runs out of money nobody cares about the rest because it won't matter. Staffing and code maintenance are a business problem but I see software developers early in their journey put too much weight on these compared to bottom line value to the company.
I have seen inexperienced developers and managers -and also developers with a lot of wrong experience- sink enormous amounts of time/money into maintaining extremely bad code without even noticing where the cost came from.
I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…
If your “mature engineers” are business- and team-focused (read: doing what they are told), disregard innovations in tech and evolution (and evangelism) of best practices, you’re gonna have a boring team that will eventually get disrupted either from outside or inside of your org.
6. Posting click bait titles to your programming blog. Edit: here's a real critique. > Best practices are non-negotiable Have you ever argued about which practice was best? I have, many times. They are endlessly negotiable, and there is no canonical list of best practices.
Non negotiable best practices does not mean it’s not arguable which practices are best. What it means is whatever you or your company decides are best practices as well as agreed upon industry best practices must be followed every time.
This is only good advice if you're solving very simple, very trivial problems, or if you don't have enough experience. (That, or if you redefine best practices to tautologies like "always test" or "always write good code").
For anything more complicated than the most trivial of software, it's important to deeply understand your best practices and if they make sense to each situation or not.
Software is hard. There are no silver bullets.