We all partake in software creation, as developers, architects, analysts…
This category covers topics for all these people and probably more, from coding tools and best practices to architecture and management recommendations.
Now, you’re willing to help, but you can’t see how you can make a difference because work on software exclusively and have no say about the hardware that it’ll run on?
This post will give you some hints about how to include these considerations into the design of your application.
The end of the year is a good time for assessments.
A good one is, “what have I learned this year?”
IT is a field that keeps moving, and we need to stay up to date if we don’t want to drown.
In our culture, most of our knowledge is stored and shared through writing, so a part of my question becomes, “what have I read that was enlightening this year?”
I’ve discussed with several people, this year.
Technical leads, technical supervisors, architects…
You get the gist.
Among those discussions, I heard a recurring complaint, which I previously feared to be my demanding nature expressing itself.
But no! Other people noticed it too, and it basically boils down to something like this: we’re facing a new generation of developers, who like to do things fast and don’t care much about how things work deep down, and we’re living in an era proposing a new framework to help them go faster and not understand.
The two together won’t make for great developers. Good developers, maybe, but not great ones.
More than once in my—no-so-long—career, I’ve had to work on machines that were not appropriate to my development needs.
These were most often the result of company policies designed to reduce the cost of machines to a reasonable level, but that doesn’t take the specific case of developers into account.
In the (not-so-)long run, it’s actually often money sent down the drain nonetheless.