When it comes to doing any type of development – I don’t care if it’s for the web, for mobile, or for some other platform – there are plenty of books, online courses, and so on that make it incredibly easy to learn whatever it is you want to learn.
To be clear, I’m not knocking any of the ways that are available to learn, either. After all, we all learn in different ways, right? And who am I say which way is better than any other way especially given the fact I write daily about topics here on and on other sites?
But I can definitively say for me – someone who has enjoyed both learning through formal education, tutorials, courses, and so on – the best way to gain experience in this industry has been two fold:
- working with other people,
- breaking things, and learning how to fix them.
Do I mean doing it in this specific order? Nope. Does this mean I’m leaps and bounds ahead of others? That’s laughable.
But as I have had the pleasure of working with others on multiple projects, talking with others via Twitter, conferences, and so on and experienced both the good and the bad, it’s something I think everyone should have the opportunity to do at some point.
If I had to summarize it, I’d say that it’s about finding a balance of team-based pragmatism and engineering. Why, though, if nothing of the above is new (given software companies have existed for decades) am I bothering to write about this now?
Team-Based Pragmatism and Engineering
I could probably come up with a laundry list of reasons as to why I find this particular topic important, but there are three specific things I’d like to mention in this post. And, for the sake of length (read: time), I’ll do what I can do keep them short.
In fact, the TL;DR of what I’m going to talk about has to do with pragmatism and engineering skill. Originally, I was also going to include a perspective on business-in-general, but it took the general post a bit off topic.
1. Pragmatism
I’ve written about balancing engineering and pragmatism before. So I may not have much to offer to in the way of anything new, but I’m beginning to change my perspective a little bit.
That is, at one point, it was strictly about finding a balance between finding a solution that works for the custom, that’s well-built, and that solves their problem. And I still subscribe to that.
And, of course, there’s something to be said for how the code is organized so it can be maintained over time. That’s key. But how the code is built is written and the solution is built is where things that can get a little more blurry with respect to pragmatism.
That is to say it’s easy to write basic object-oriented code, document it, have a few classes or functions call one another, hook into WordPress, and then call it a day.
2. Engineering Skill
But is that level of balancing shipping the solution and architecting the solution is a fine line to walk. I believe, though, there’s a danger in trying to be too pragmatic: If you aim to stay as pragmatic as possible all the time and leave your engineering skills at a particular level, you may fail to progress as a developer.
Though I prefer to use object-oriented programming in the type of work I do, I’m not one to get into a religious war or get into what version of what language, what technology, or if functional, procedrual, or object-oriented programming is better.
Simply put: it’s about the general level of skill you can attain throughout your career.
And when I work with developers who have worked on projects of different skills, who have been educated in different ways, and who have solved different types of problems, I find I consistently learn new things.
This isn’t to say there aren’t conversations around things we may implement as a team or as a partnership, but it is to say it can prevent stumping the potential to grow as a programmer.
I could go on about this, but the short of it is this: If you’re going to work with others, make sure they are experienced, enjoy using the same type of paradigms you do, are open to thoughtful conversation, and bring a variety of experience to the table.
Ultimately, this can help improve both your ability and the quality of what you and your team are bringing to the table.
There’s Always More
As I said earlier in the post, there’s always more. I’ll likely talk more about the business aspect of it in future posts.
For now, though, I’ll leave what I’ve written where it sits and will go from there later.
