I wouldn’t say programming is about logic and algorithms. It’s a bit like saying carpentry is about nails and saws. Logic and algorithms are part of the arsenal of what you use in writing software, but the act of writing software itself is something bigger and broader.
Writing software (programming) is about expressing ideas, concepts, processes and relationships in a form that can be executed on a computer.
That may sound a bit pretentious, but it’s not really. My writing this answer is expressing ideas. Speaking to someone expresses ideas. Mathematics is a way of expressing ideas. Certain hand gestures express quite emotional ideas. With a computer, we’re expressing ideas in a specific form that the computer is able to do something with.
The computer language you use is only the basic part of that. It has a syntax and semantics that allow some basic data types to be expressed and some fundamental operations to be done. What a computer language has, though, that makes it powerful is that by doing things like creating variables with name, creating new data types with names, lumping data together into structures with names, and lumping executable statements into functions with names, it allows us to extend the language, to create our own vocabulary (often based on the real world or on ideas outside the language), to talk about the kinds of things we need to and want to in order to have the computer do what we want but also express what we’re thinking in a way, such that we think the resulting behavior will actually reflect what both what we intend it do and what we intend it to mean.
We can take this to an even higher level - if we lump data types and functionality together, we can create things like libraries and frameworks. If you think about it, the defined API for a library or framework is the realization of some programmers’ idea of how to accomplish some task. It has data types that the programmer(s) thought captured the data necessary. The ways of transforming and moving that data around are an embodiment of how the programmer views the system. That is why some APIs make sense to us and some don’t, why some are easier and some are harder to grasp - it depends on how much the way we think about a problem is in tune with how the person or people who created the API thought about the problem… or how much we can change the way we think about it to get into the mindset of those who wrote it.
I have seen some horrific code, and it’s usually a reflection of the state of mind of the programmer who wrote it. If the person writing the code has a clear idea of what they’re trying to communicate (and are able to express it well), then the code will usually be reasonable. If the programmer is having a hard time making sense of what they’re trying to do - what the operations are, what the key data structures are, what the relationships among the pieces are, etc. - then the code will typically reflect that, unless they get very, very lucky. And it will usually have bugs and be hard to modify.
So why is it important to know things like frameworks? Because that is often a significant part of the vocabulary that you will be using when you’re working with that codebase. That’s true of everything in a code base, but when working with frameworks, you often spend more time trying to figure out how you’re supposed to make things work - and coming up with best practices to do so - than you are doing things like inventing novel algorithms. You’re trying to get inside someone else’s head. Having experience in that framework will allow you to hit the ground running, having (hopefully) already made all the mistakes a newbie would make in that sort of framework.
Now in my experience, companies aren’t usually hard-nosed about people they’re hiring knowing the framework or tech inside and out, unless they have a glut of qualified candidates who do know the framework or tech, in which case you’re a bit out of luck if you don’t. It’s definitely a plus, but if the candidate seems like they would be able to come up to speed fairly quickly and be able to be productive - typically because they have a range of experience and a proven track record - then the person could well be a good hire (assuming they fit the corporate culture) even if they don’t yet have specific experience with the tech in question.
Credit :- jay Nabonne
0 Post a Comment:
Post a Comment