One of the things that I’ve begun to think about as I move through my career in development is what it means to be truly pragmatic about the work that I do.
But first (and no, this is not an affiliate promotion), I think it’s worth noting that The Pragmatic Programmer is a book that I think every person who is a developer of some sort should reading (maybe several times, even). It’s an easy read and brings up a lot of good points as it relates to being the best programmer that you can be as it relates to best practices (whatever that may look like for your slice of the industry).
Anyway, I’ve talked about the tension of having to stay on top of every new technology that’s released as well as the importance of going deep rather than wide as it relates to the work that we’re doing on a day-to-day basis.
A Pragmatic Programmer
What does it mean to actually be pragmatic? According to the definition, being pragmatic or practicing pragmatism (or however you see it used) is defined as:
dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations.
And yes, there’s an entire Wikipedia article about it, too (but is that really a surprise?). There are a lot of ways that this could be generalized to speak about generic programming, or web development, or mobile development, or .NET development, and so on.
But I’m obviously most interested in what this looks like as it relates to being a WordPress developer.
Pragmatism and WordPress
Speaking purely at the general level, because of the various languages that are needed to build working solutions in WordPress, we’ve a wide variety of tools that we can use. For example, some of the more popular ones (or some of the ones that have come to mind when drafting this) are as follows:
There’s obviously a lot of options that we have when it comes to managing the assets, dependencies, and build processes of our work. I don’t consider that a bad thing.
The thing is, the nature of our culture – that is, the development culture – is that we have some people who will aim to make you feel inferior if you’re not familiar with whatever tools they opt to use.
And that sucks.
Don’t let anyone let you feel like a lower quality developer because you know or you don’t use whatever tools they use. That’s immaturity on their part. You can always learn new tools (people do it everyday both in our industry and in others).
Anyway, regardless of if you’re a one man shop, a two man shop, or a medium-to-large team, there’s no silver bullet set of tools that you can find to maximize your productivity. Instead, there’s a suite of tools available from which you can pick to build your own toolbox that’s ideal for your team.
The only caveat, in my opinion, is whatever it is that you opt to use, make sure that it doesn’t misplace good engineering practices. When your tools override good engineering, the tool is likely creating more problems – like technical debt – than it is solving. But that’s content for another post.
Anyway, the point is: Part of being a pragmatic programmer is not necessarily becoming well-versed in every single thing that comes along. It’s knowing what’s available, determining whether or not it’s a good fit for you and/or your team’s workflow, and opting to use it.
Bravo Tom,
The rush to the latest buzz can be detrimental to our growth as Software professionals. We see the tweets, articles, online courses, and all the buzz about the new tool or thingy out there on the market. The “implied message” is “you are less of a software dev if you are not using xyz.” Wrong.
Each of the utilities you listed above are simply and foremost just “tools”, tools to make our jobs easier. That’s it. None of them will make you a better developer. None will help you craft better, higher quality code. None will help you understand the code.
Rather, these are simply just tools. Granted they will save you time, once you know how to use them. I use Sass to help me modularize my CSS. But if you do not know CSS, Sass will not help you.
You start by knowing the code and implementing proven software design principles and patterns. Then you “can” (you don’t have to) use these tools to help you in your daily workflow.
Let me share a quick story to illustrate.
A family member was into carpentry. He went out and spent a bucket load of money on all the tools power tools and top of the line carpentry hand tools. Then we set out to build a hutch. He had no idea about inlay, dovetailing, or the fine-detail work that sets a quality piece of furniture apart from one at a rummage sale. He skipped the steps of learning the craft…first.
Happy coding,
Tonya
> The rush to the latest buzz can be detrimental to our growth as Software professionals. We see the tweets, articles, online courses, and all the buzz about the new tool or thingy out there on the market. The “implied message” is “you are less of a software dev if you are not using xyz.”
Wrong.
I agree with you. That’s _exactly_ how it is.
It’s becoming more and more pervasive in our culture, too and that’s a bummer. It’s not that I dislike the tools – obviously, I use my own set and I enjoy using them – but it’s the mentality that others have of “If you’re not using [this tool], then you’re definitely not as qualified for [writing whatever kind of code].”
We can all learn new tools. Give us a few hours and we’ll generally be fine especially if there’s solid documentation.
> Each of the utilities you listed above are simply and foremost just “tools”, tools to make our jobs easier. That’s it. None of them will make you a better developer. None will help you craft better, higher quality code. None will help you understand the code.
Bingo.
> Rather, these are simply just tools. Granted they will save you time, once you know how to use them. I use Sass to help me modularize my CSS. But if you do not know CSS, Sass will not help you.
That’s a good way to phrase it.
> You start by knowing the code and implementing proven software design principles and patterns. Then you “can” (you don’t have to) use these tools to help you in your daily workflow.
Yep – and that’s where most of the programmers who I know, respect, and try to learn from currently are (or the path they followed).
They started off with the basics of writing code and building software and then moved up into using a variety of other tools to help automate their processes.
Super simple case in point: Site deployment used to be building the site on the local machine then uploading it via FTP.
Now we have processes in place for committing code into GitHub, generating Changelogs, then doing an automated build and deployment with another tool upon each checking that’s hooked into a chat room or Slack channel in order to notify those of us who are all working on the codebase.
It’s really neat, but I’d _never_ try to start there. Not unless I was coming into a larger company who already had that in place, but that’s content for an entirely different post.
> Let me share a quick story to illustrate.
> A family member was into carpentry. He went out and spent a bucket load of money on all the tools power tools and top of the line carpentry hand tools. Then we set out to build a hutch. He had no idea about inlay, dovetailing, or the fine-detail work that sets a quality piece of furniture apart from one at a rummage sale. He skipped the steps of learning the craft…first.
Well said.
I’ve caught myself feeling like I must be an inferior developer just because I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM. I know a lot, have been making web sites since the time when frames were the hot new thing, and can mentally break a large project down into the code components that need to be written. But since I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM, I’ll find myself feeling like I’m not good enough.
The worst part is that when you learn $HOT_NEW_WEB_PROGRAMMING_ITEM, something new comes along to make you feel inferior for not knowing. You could devote 100% of your time to learning new tools/languages and still not get up to date. (And you wouldn’t have time to actually write anything which is the point of all of this stuff.)
It’s like that treadmill in the Jetsons. If you’re not careful, you’ll get caught up in it and spun around and around. Jane, stop this crazy thing!!!
> I’ve caught myself feeling like I must be an inferior developer just because I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM. I know a lot, have been making web sites since the time when frames were the hot new thing, and can mentally break a large project down into the code components that need to be written. But since I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM, I’ll find myself feeling like I’m not good enough.
I’m beginning to think this is something we all identify with, but no one is actually talking much about it.
Or not talking _as much_ about it as we could. Perhaps we should start a “Inferiority Anonymous” group ;P.
> The worst part is that when you learn $HOT_NEW_WEB_PROGRAMMING_ITEM, something new comes along to make you feel inferior for not knowing. You could devote 100% of your time to learning new tools/languages and still not get up to date. (And you wouldn’t have time to actually write anything which is the point of all of this stuff.)
It’s a vicious cycle, isn’t it?
On Fri, Jul 31, 2015 at 9:17 AM, TechyDad wrote:
> Tom McFarlin >
> TechyDad replied to your comment on Being a Pragmatic Programmer in > WordPress <https://tommcfarlin.com/pragmatic-programmer-in-wordpress/>: > TechyDad <http://www.TechyDad.com/> >
> It’s becoming more and more pervasive in our culture, too and that’s a > bummer. It’s not that I dislike the tools – obviously, I use my own set and > I enjoy using them – but it’s the mentality that others have of “If you’re > not using [this tool], then you’re definitely not as qualified for [writing > whatever kind of code].” >
> I’ve caught myself feeling like I must be an inferior developer just > because I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM. I know a lot, have been > making web sites since the time when frames were the hot new thing, and can > mentally break a large project down into the code components that need to > be written. But since I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM, I’ll find > myself feeling like I’m not good enough.
>
> The worst part is that when you learn $HOT_NEW_WEB_PROGRAMMING_ITEM, > something new comes along to make you feel inferior for not knowing. You > could devote 100% of your time to learning new tools/languages and still > not get up to date. (And you wouldn’t have time to actually write anything > which is the point of all of this stuff.) >
> It’s like that treadmill in the Jetsons. If you’re not careful, you’ll get > caught up in it and spun around and around. Jane, stop this crazy thing!!!
> Reply to this email to reply to TechyDad.
> Here’s a recap of this post and conversation: >
> Being a Pragmatic Programmer in WordPress > <https://tommcfarlin.com/pragmatic-programmer-in-wordpress/> was > published on July 30, 2015 by Tom.
>
> Don’t let anyone let you feel like a lower quality developer because you > know or you don’t use whatever tools they use. That’s immaturity on their > part. You can always learn new tools (people do it everyday both in our > industry and in others). Anyway, regardless of if you’re a one man shop, a > two man shop, or a medium-to-large team, there’s no silver bullet set of > tools that you can find to maximize your productivity. Instead, there’s a > suite of tools available from which you can pick to build your own toolbox > that’s ideal for your team. The only caveat, in my opinion, is whatever it > is that you opt to use, make sure that it doesn’t misplace good engineering > practices. When your tools override good engineering, the tool is likely > creating more problems – like technical debt – than it is solving.
> There were 6 comments > <https://tommcfarlin.com/pragmatic-programmer-in-wordpress/#comments> > previous to this. Here is this reply in context: > Tonya <https://wpdevelopersclub.com> >
> Bravo Tom, >
> The rush to the latest buzz can be detrimental to our growth as Software > professionals. We see the tweets, articles, online courses, and all the > buzz about the new tool or thingy out there on the market. The “implied > message” is “you are less of a software dev if you are not using xyz.” > Wrong.
>
> Each of the utilities you listed above are simply and foremost just > “tools”, tools to make our jobs easier. That’s it. None of them will make > you a better developer. None will help you craft better, higher quality > code. None will help you understand the code.
>
> Rather, these are simply just tools. Granted they will save you time, once > you know how to use them. I use Sass to help me modularize my CSS. But if > you do not know CSS, Sass will not help you.
>
> You start by knowing the code and implementing proven software design > principles and patterns. Then you “can” (you don’t have to) use these tools > to help you in your daily workflow.
>
> Let me share a quick story to illustrate.
>
> A family member was into carpentry. He went out and spent a bucket load of > money on all the tools power tools and top of the line carpentry hand > tools. Then we set out to build a hutch. He had no idea about inlay, > dovetailing, or the fine-detail work that sets a quality piece of furniture > apart from one at a rummage sale. He skipped the steps of learning the > craft…first.
>
> Happy coding, >
> Tonya > Tom <http://tommcfarlin.com> >
> > The rush to the latest buzz can be detrimental to our growth as Software > professionals. We see the tweets, articles, online courses, and all the > buzz about the new tool or thingy out there on the market. The “implied > message” is “you are less of a software dev if you are not using xyz.” > Wrong.
>
> I agree with you. That’s _exactly_ how it is.
>
> It’s becoming more and more pervasive in our culture, too and that’s a > bummer. It’s not that I dislike the tools – obviously, I use my own set and > I enjoy using them – but it’s the mentality that others have of “If you’re > not using [this tool], then you’re definitely not as qualified for [writing > whatever kind of code].” >
> We can all learn new tools. Give us a few hours and we’ll generally be > fine especially if there’s solid documentation.
>
> > Each of the utilities you listed above are simply and foremost just > “tools”, tools to make our jobs easier. That’s it. None of them will make > you a better developer. None will help you craft better, higher quality > code. None will help you understand the code.
>
> Bingo.
>
> > Rather, these are simply just tools. Granted they will save you time, > once you know how to use them. I use Sass to help me modularize my CSS. But > if you do not know CSS, Sass will not help you.
>
> That’s a good way to phrase it.
>
> > You start by knowing the code and implementing proven software design > principles and patterns. Then you “can” (you don’t have to) use these tools > to help you in your daily workflow.
>
> Yep – and that’s where most of the programmers who I know, respect, and > try to learn from currently are (or the path they followed).
>
> They started off with the basics of writing code and building software and > then moved up into using a variety of other tools to help automate their > processes.
>
> Super simple case in point: Site deployment used to be building the site > on the local machine then uploading it via FTP.
>
> Now we have processes in place for committing code into GitHub, generating > Changelogs, then doing an automated build and deployment with another tool > upon each checking that’s hooked into a chat room or Slack channel in order > to notify those of us who are all working on the codebase.
>
> It’s really neat, but I’d _never_ try to start there. Not unless I was > coming into a larger company who already had that in place, but that’s > content for an entirely different post.
>
> > Let me share a quick story to illustrate.
>
> > A family member was into carpentry. He went out and spent a bucket load > of money on all the tools power tools and top of the line carpentry hand > tools. Then we set out to build a hutch. He had no idea about inlay, > dovetailing, or the fine-detail work that sets a quality piece of furniture > apart from one at a rummage sale. He skipped the steps of learning the > craft…first.
>
> Well said.
> TechyDad <http://www.TechyDad.com/> >
> It’s becoming more and more pervasive in our culture, too and that’s a > bummer. It’s not that I dislike the tools – obviously, I use my own set and > I enjoy using them – but it’s the mentality that others have of “If you’re > not using [this tool], then you’re definitely not as qualified for [writing > whatever kind of code].” >
> I’ve caught myself feeling like I must be an inferior developer just > because I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM. I know a lot, have been > making web sites since the time when frames were the hot new thing, and can > mentally break a large project down into the code components that need to > be written. But since I don’t know $HOT_NEW_WEB_PROGRAMMING_ITEM, I’ll find > myself feeling like I’m not good enough.
>
> The worst part is that when you learn $HOT_NEW_WEB_PROGRAMMING_ITEM, > something new comes along to make you feel inferior for not knowing. You > could devote 100% of your time to learning new tools/languages and still > not get up to date. (And you wouldn’t have time to actually write anything > which is the point of all of this stuff.) >
> It’s like that treadmill in the Jetsons. If you’re not careful, you’ll get > caught up in it and spun around and around. Jane, stop this crazy thing!!!
> Reply to this email to reply to TechyDad.
> Leave this conversation >
> To no longer receive other comments or replies in this discussion reply > with the word ‘unsubscribe’.
>
> Sent from Tom McFarlin <https://tommcfarlin.com>. Delivered by Postmatic > <https://gopostmatic.com/?utm_source=footer&utm_medium=email&utm_campaign=pluginfooter>.
>
>
—
It’s the loss of control that often bothers me. Or the apparent loss of control. Processes and skills get abstracted away by tools (as listed above), and you come to rely upon the tool and not your basic skills. Your new important skill becomes using the tool, not being able to create what you used to create by hand before you had the tool.
I sound like a Luddite, right? It’s the reason I’ve resisted getting deeper into Laravel and prefer working with Processwire or a really basic framework like F3. Many WordPress plugins or themes leave me cold since they force you to rely on the custom code of others.
Sure, there’s a compromise position, but so many tools require an all or nothing opt-in.
> It’s the loss of control that often bothers me. Or the apparent loss of control. Processes and skills get abstracted away by tools (as listed above), and you come to rely upon the tool and not your basic skills. Your new important skill becomes using the tool, not being able to create what you used to create by hand before you had the tool.
This is a valid point – I think that there’s something to be said for understanding exactly that the tool is doing and why it’s saving you time before you use it (or whenever you start to use it).
I think that this is somewhat of a slippery slope though, because if you take that same idea and you apply it to our basic programming languages then how far down do we go? Do we eventually drop down to C or Assembly where memory management is happening?
Personally, I don’t think that’s absolutely necessary, but I also think that it’s worth having _at least_ a conceptual understanding of what’s happening. It’s not a requirement, though, but a “nice-to-have.”
> I sound like a Luddite, right? It’s the reason I’ve resisted getting deeper into Laravel and prefer working with Processwire or a really basic framework like F3. Many WordPress plugins or themes leave me cold since they force you to rely on the custom code of others.
On some level, aren’t we all relying on the code of others, though? I mean even when you’re building on top of other things like Laravel, Processwire, WordPress, Rails, .NET, and so on, you’re building on the work of others.
So I think it’s just a matter of _how much_ do you want to be able to do yourself and _how much_ do you want abstracted (which is what your initial point was, I suppose :).
> Sure, there’s a compromise position, but so many tools require an all or nothing opt-in.
Yeah — I’ve found though, at least in my experience, that people general opt-in when they get tired of the tedious nature of what they’re already doing.
On Thu, Jul 30, 2015 at 11:16 PM, rngelliot wrote:
> Tom McFarlin >
> rngelliot added a comment in reply to Being a Pragmatic Programmer in > WordPress <https://tommcfarlin.com/pragmatic-programmer-in-wordpress/>.
>
> It’s the loss of control that often bothers me. Or the apparent loss of > control. Processes and skills get abstracted away by tools (as listed > above), and you come to rely upon the tool and not your basic skills. Your > new important skill becomes using the tool, not being able to create what > you used to create by hand before you had the tool.
>
> I sound like a Luddite, right? It’s the reason I’ve resisted getting > deeper into Laravel and prefer working with Processwire or a really basic > framework like F3. Many WordPress plugins or themes leave me cold since > they force you to rely on the custom code of others.
>
> Sure, there’s a compromise position, but so many tools require an all or > nothing opt-in.
> Reply to this email to reply to rngelliot.
> *Please note*: Your reply will be published publicly and immediately on Being > a Pragmatic Programmer in WordPress > <https://tommcfarlin.com/pragmatic-programmer-in-wordpress/>.
> Recently in this conversation…
> Tonya <https://wpdevelopersclub.com> > July 30, 2015 at 10:06 am >
> *Bravo Tom, The rush to the latest buzz can be detrimental to our growth > as Software professionals. We see the tweets, articles, online courses, and > all the buzz about the new tool or thingy out there on the market. The > “implied message” is “you are less of a software dev if you are not using > xyz.” Wrong. Each of the utilities you listed above are simply and foremost > just “tools”, tools to make our jobs easier. That’s it. None of them will > make you a better developer. None will help you craft better, higher > quality code. … * > Ross > July 30, 2015 at 11:16 pm >
> *It’s the loss of control that often bothers me. Or the apparent loss of > control. Processes and skills get abstracted away by tools (as listed > above), and you come to rely upon the tool and not your basic skills. Your > new important skill becomes using the tool, not being able to create what > you used to create by hand before you had the tool. I sound like a Luddite, > right? It’s the reason I’ve resisted getting deeper into Laravel and prefer > working with Processwire or a really basic framework like F3. Many > WordPress plugins or themes leave me cold since they … * > Reply to this email to reply to rngelliot.
> *Please note*: Your reply will be published publicly and immediately on Being > a Pragmatic Programmer in WordPress > <https://tommcfarlin.com/pragmatic-programmer-in-wordpress/>.
> Want to leave this conversation?
>
> To no longer receive other comments on this thread reply with the word > ‘unsubscribe’.
>
> Sent from Tom McFarlin <https://tommcfarlin.com>. Delivered by Postmatic > <https://gopostmatic.com/?utm_source=footer&utm_medium=email&utm_campaign=pluginfooter>.
>
>
—
I’ll feel that way too, at times. I come from the era when programming for the web meant opening Notepad and writing all of your HTML code by hand. We didn’t have any fancy CSS or JavaScript. Hey, you kids, get off my lawn!
Of course, there needs to be a balance between “writing it yourself” and “not reinventing the wheel.” Before WordPress, I would write all client’s sites completely from scratch by myself. All bugs would need to be addressed by me and all new features coded by me. It was nice to program it all, but it would get tedious at times. Now, I can just take WordPress and build upon the foundation it provides. I don’t need to reinvent everything and my coding can move to a higher level because I’m standing atop the work that others have done.
I totally agree with Ross.
And I’d go further as well: the abstracting tools get in the way too much. In my own experience I’ve been frustrated by having to achieve a basic mastery of tools like composer, grunt, gulp, ruby an so on… when I could be putting that time and energy into deepening my mastery of actual programming.
In order to get a pre-processor running I typically have to install the correct version of node atop a version-managed ruby. So I have to know the basics of ruby, rvm or rbenv and node. This isn’t harmful. But it feels like an obstacle instead of a gateway.
Of course, commercial productivity relies on using these toolsets.
There’s no ideal solution. We just have to learn as much as we can of as many of these tools as we can. Perhaps one magical day the industry will have standardized on fewer abstracting tools. And perhaps those toolsets will “just work” one day, without me having to understand their depth. (gulp streams and the node event loop? I just want my scss to compile!)
It all reminds me of my introduction to programming. It took me an embarrassingly long amount of time to build a “hello world” in Java because I couldn’t figure out how to make the classpath accessible. Decades later I still feel myself in a similar bind sometimes.
> And I’d go further as well: the abstracting tools get in the way too much.
This is what happens when you rely too much on tooling, in my opinion. It’s about finding that balance of things that help you become more productive.
> In my own experience I’ve been frustrated by having to achieve a basic mastery of tools like composer, grunt, gulp, ruby an so on… when I could be putting that time and energy into deepening my mastery of actual programming.
Totally understand that. That’s why I have to be really careful when I decide to change tools or introduce something new. The learning curve has an inherent time value that can negatively impact what it is we’re trying to do.
> In order to get a pre-processor running I typically have to install the correct version of node atop a version-managed ruby. So I have to know the basics of ruby, rvm or rbenv and node. This isn’t harmful. But it feels like an obstacle instead of a gateway.
For sure. But there _are_ some solutions that bundle all of that into a single application so you don’t have to worry about those particular details, which I tend to favor.
> There’s no ideal solution. We just have to learn as much as we can of as many of these tools as we can.
Amen.
> Perhaps one magical day the industry will have standardized on fewer abstracting tools. And perhaps those toolsets will “just work” one day, without me having to understand their depth. (gulp streams and the node event loop? I just want my scss to compile!)
My guess is that it will only get more complicated but who knows?
> It all reminds me of my introduction to programming. It took me an embarrassingly long amount of time to build a “hello world” in Java because I couldn’t figure out how to make the classpath accessible. Decades later I still feel myself in a similar bind sometimes.
I also think that Java, as a language, has an inherently tough learning curve for first time programmers. That is, just for `main` you have to understand `public`, `static`, `void`, `String[]` — that’s a lot of stuff just to gloss over for the sake of getting `System.println` or whatever library they are using now.
Sunil: “And I’d go further as well: the abstracting tools get in the way too much. In my own experience I’ve been frustrated by having to achieve a basic mastery of tools like composer, grunt, gulp, ruby an so on… when I could be putting that time and energy into deepening my mastery of actual programming.”
Exactly. And it’s a little annoying at times. It feels like a road block.
I suspect what happens is people develop a copy & paste mentality. They simply use the demo Gulp/Composer, etc. setup scripts without really learning what’s going on. It works, so they shrug their shoulders and move on, satisfied they’ve jumped on the bandwagon, but they’ve just become reliant on something they don’t really understand, and that’s a huge future problem, and security issue. But who’s got the time? There’s still too many WP core functions I haven’t learned properly and that’s what I want to focus on.
It’s always a compromise and we must choose wisely. That’s the trick. Resist the latest craze.
Now what the hell is taking that Windows 10 download so long…?
;-)
This post addresses a trend that is quite prevalent now, and I like the approach that was taken to address it.
Even as a simple web “worker” who doesn’t consider themselves a developer per se, I’ve recently observed an increased layering of complexity on top simple processes, to the point where the original intent and purpose is lost in the myriad of tools and tooling.
Part of me believes this to mostly be the result of a marketing tactic, aimed at “owning” and controlling the emotions of software makers, developers, and users, to the point where we’re emotionally invested in a “branded product” that (for example) does the same thing as “copy and paste”.
So we evangelize the product, and proselytize its high values and efficiency benefits, above all other tools.
Its just like what Uncle Bob explains in his talk to the COHAA (the Path to Agility Conference), back in 2012, about corporations trying to gather the “hearts and minds of programmers”.
But here’s the thing: that product is usually built on top of something else. And there’s limitations to every kind of software.
What happens when the limitations kick in?
Its followers start looking for new clay feet….rapidly.
Meanwhile, folks who have simply mastered the basics remain standing.
Kudos on a great post, Tom.
Well said Tom.
The process is a journey, not a destination. Balancing the desire to chase “shiny new objects” over using the knowledge and tools I already have to solve a business problem – is not always easy.
These distractions can sometimes paralyze creative thought and problem solving skills, because I feel I’m not using the best tool to complete the task. Every time I see a piece of code that I don’t understand, I ask myself – “Do I need to understand this right now? Is this something that will help me with the current project I am working on?” If not – I add it my list of things to explore when I do have time. Then I prioritize that list based on my plan that considers current needs and future development path.
I think the way you’re prioritizing things is spot on – I think it’s really pragmatic. I understand the paralyzation that comes with not necessarily understanding everything as you come across it.
It’s tough – everything inside of me wants to know _exactly_ what’s going on, but the time required to actually dive deep into everything would far outweigh the amount of time I have to get _my_ things done.
So, like you said, it’s a matter of really prioritizing and then going from there.
—
This post is also very beneficial to new learning devs like myself. I feel so swamped with the amount of learning that seems to be required when in actual fact, newbies should take note on this and keep to the base fundamentals of programming whilst on our path to mastery.
For any industry, I’m sure designers have this issue too, so same rule applies!
I myself am going all in with php and learning the WordPress core as my beginning path.
Exactly – it’s really tough to get into the game and then not to feel overwhelmed. The best advice I can give is to find a core set of tools and languages with which you want to work and then go after those with all you’ve got.
Not fitting in with what you want to do? Try something new but repeat it with a level of intensity. It can be tough to find what it is you’re looking for with respect to all of this, but eventually you find your niche and when you do it’s a lot more fun to get your work done.
Go for it (and welcome :).