The Creative Word
Excerpt:
If you drink the Kool-Aid, the key phrases to the microsservices bandwagon are:
The irony here is that we’ve heard pretty much the same mantra starting with object oriented programming / architecture / design, so why are microservices now suddenly (one of) the in-vogue solution to problems that have not been already solved?
Read more on Code Project.
Just a random observation — I’m saddened when I encounter a management mentality that makes no effort to educate their junior devs so they can eventually become senior devs.
If you don’t have a decent knowledge of the programming language, framework and tools you’re working with, the way you “code” is like someone with a 3rd grade vocabulary trying to express a complex thought.
How do you educate junior devs?
Realistically though, nothing can overcome the “it’s a job, not a passion” attitude in the junior dev him/herself. If the junior dev has a passion for software development, they’ll most likely educate themselves on their own time, not just the company’s time.
But then, when they have learned, they’ll move on because the work environment suddenly becomes limited. An interesting dilemma for management, especially as they can now ask for a considerably higher salary than the company wants to pay for, which is why they hired junior devs to begin with.
In TechChrunch, the author writes:
Do you work in software? Do you have more than a decade of experience? You do? I’m sorry to hear that. That means there’s a strong possibility that much of what you know is already obsolete.
Certainly much of what I have learned in the technical realm is certainly obsolete. I haven’t coded in 6502, Z80, 8086, Cobol, Fortran, Pascal, C, or C++ in ages.
But much of what I’ve learned about writing documentation, communication, debugging, creating flexible architectures, making accurate time estimates, designing intuitive UI’s, and getting skilled at teaching others, those are skills that never become obsolete.
The most important skill, one that truly doesn’t get old, is the meta-skill of constantly learning new things … and that meta-skill can rust and wither away, too, if it languishes unused.
Agreed, but the skill of learning new things isn’t the only meta-skill.
Granted, I borrowed that image from here, where the author views people like me as “unhappy dogmatists who can’t bring themselves to leave the kiddie pool of strong typing.” Yes, I am rather dogmatic about strong typing! But to the point…
David R. Maclver wrote an interesting post “Static typing will not save us from broken software.”
Riiight.
davidMacIver = HesGotSomeGoodPoints() davidMacIver = ButHesAlsoWrong()
Make it more expensive to write broken software – write in a non-static typed language
Make it cheaper to write correct software – write in a static typed language
But because these bugs [those that happen in production] are relatively minor
Now that’s where I totally disagree. If a true static typed language had been used, or had been used properly (ie, semantically, which is the next level of strong typing), this case in point[^]
due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf s) instead of the SI units of newton-seconds (N s) specified in the contract between NASA and Lockheed.
would not have cost the taxpayers $327.6 million
Dealing with type errors in a non-static language is not cheaper. I spend time writing unit tests and verifying the runtime by hand to ensure type correctness that I do NOT spend with static typed languages. Running an app only to discover I’m using a duck-typed variable before I’ve assigned something to it is a time waster. The benefits of static typing far outweigh the benefits of non-static typed languages, and I’m sorry David, that’s not opinion, but measurable fact.
Can duck-typed languages save time? Sure! I can replace a class instance that interfaces with hardware with a class instance that mocks the hardware as simply as the code above. I can add fields to a class outside of the class simply by making an assignment.
All of which are cheats and laziness, break the “code as documentation” fallback, and make duck-typed code more error prone and difficult to maintain.
Most existing static type systems also come with a build time cost that makes testing in general more expensive.
And the unit tests that duck-typed languages require often (in my experience with a small Ruby on Rails web app) take longer to run than compiling much more complex web sites.
SD Times posted about three groups of technologies that can change the world. One has to ignore the babble-speak:
Quite so. But I wonder at the tag line “change the world.” I would assume they are referring to that part of the world that has access to electricity, potable water, food, health care, the Internet, and isn’t worried about starvation, disease, dictators, and terrorist groups. Yeah, that world.
Marc Clifton 