Working with the same group of people for 20 years is probably as bad for your creativity as working on the same project for the same company as long. Your skills stagnate, your ideas become inbred, your work becomes outdated, and your growth becomes limited by the Clique that helped you earlier in your career.
Author: Oleg Dulin
Stop Shakespearizing
Ultimately, you must know your project, your needs, yourself, your skills, and your team. Only you are responsible for your project. So trust your instincts, fellow architect, and don't Shakespearize 🙂
Using GNU Make with JavaScript and Node.js to build AWS Lambda functions
In the upcoming series of articles, I will show examples of using `make` to orchestrate builds of JavaScript apps. Today, I want to talk about using make to build Node.js-based Lambda functions.
Why don’t they tell you that in the instructions?
The nature of our jobs as software engineers is such that we must deal with externalities. Hardware will crash. Services will auto-scale up and down. Garbage collection will occur. Humans will make mistakes and use our software in ways we did not anticipate. Someone will write configuration instructions for you on how to setup your dev environment, and they might not apply perfectly to your setup.
Monolithic repository vs a monolith
Monorepo makes sense under some circumstances and makes no sense under others. A set of related features with related code, similar security, performance, and scalability profiles belong in a single deployable service. Services that are functionally related and have a closely aligned release cycle belong to the same monorepo.
All developers should know UNIX
If you are a developer, you cannot avoid learning UNIX. You may be able to get by day-to-day with graphical tools, and you will not advance your career without learning and understanding the UNIX ecosystem. To be productive as a developer is to know UNIX.
Keep your caching simple and inexpensive
Caching is a complex topic. It can make your application perform faster, and it can also make your life living hell. Here are some things I learned from experience.
Scripting languages are tools for tying APIs together, not building complex systems
What makes me think of these things early in the mornings is the proliferation of Java*Script* as an enterprise application language. I believe using JS as a hammer to solve every problem will hound enterprise IT for decades.
Good developers can pick up new programming languages
We shouldn’t be recruiting developers based on some single technology they know but on what they can learn and apply in the future. A generalist developer that can pick the right tool for a given taskand articulate why they made such a decision is a lot more valuable than a specialist.
Java is no longer relevant
Though Java was my primary way of earning a living from about 1997 to 2015, it has long outlived the problems it solved. Java’s issues are being solved now by modern tools like Docker. Except for a few niche use cases, I no longer use Java for my projects.
You must be logged in to post a comment.