The art of software engineering is to make great use of what you already know in order to produce something new.
I’ve seen a lot of development efforts fail when the developer gets lost in a sea of uncertainty and starts to analyse the world in a vain attempt to choose the perfect option. The reflector/theorist types can quickly get lots in the swirling void of possibilities and deliver nothing because the more they research the less they feel they can actually do.
While we should respect different personality types and learning styles, allowing people to spend some time getting oriented with new technologies, there’s no substitute for whacking a stake in the ground and making something happen.
Very much like Captain Picard’s “make it so”, “make something happen” is quite a nice catchphrase for setting a goal for the next couple of hours of development.
But if you never tool up, then your workspace becomes a clutter of unruly hacks.
By tooling up, I mean refining an effective process and tool set for the thing you’re trying to do. It fits nicely with the Red – Green – Refactor cycle.
- We don’t know how to do something
- We figure out some basic way to get results
- We harness our success to work out how to make more such results more effectively
Tooling up might be as simple as choosing the best IDE for what you’re doing. Perhaps Visual Studio Code is the most efficient for your use case? Perhaps Atom is, and you just need a couple of handy shell scripts. Maybe Eclipse has the perfect plug-in. Most likely IntelliJ is the answer, because it almost always is.
When you’ve chosen that tool, you ought to eradicate other variations within the team. Teams can tolerate some diversity of tooling, but the “it doesn’t work on mine” syndrome is more easily removed if you’re all on the same platform. The same is true for operating system. Unless it really isn’t causing an issue.
To that end, make sure everyone has the same version of the platform you’re using to develop with. We can’t all work together with different language variants and tools – you end up with warring config files. The same is true for linter settings, code reformatters etc. Much of this can be set up in the code repository.
Have a CI/CD process. If you think that manually deploying to your test environment is acceptable, then you’ve been living in an abusive relationship with your job and employer and need to snap out of it. Manual deployment to any environment, including the developer workstation, is for the first few hours of a project where you’re in the dark and working out how to do things.
Have a scripted local deploy. A start-script that you can run to get the software in a working known state on your developer machine is a must. Without it you’re mucking about with half-remembered commands.
Take time to learn the tech. Sure, you may have pasted some stuff in from StackOverflow to get going. Now work out how it works and whether it’s right for you. Take a few moments to understand the structure and the options. Don’t research the world for it, but get the quick start, so you know how to move forward with it.
If you don’t take ownership of your development environment, then you’ll be a victim of it, not the creative development force you’re meant to be.