Come yung’uns, gather by the fire that I may tell you a story… well more of a walk-through really… The older kids have heard it before and have gone on their separate ways… Now, you’ll hear it and make your choices and go your separate way… I see you’re all fresh-faced and want to make a splash at being a developer but you feel inexperienced and unequal to some of the bigger boys and girls out there. You wonder, ‘what can I do to become a pro ASAP?’ Well huddle ’round the fire quickly and listen, before you start asking yourself why are a bunch of ‘young’ developers huddling around a fire to listen to an old man? Wait, what’s happening, where are we?!
Well, that’s it yung’uns… Any questions or something you need more explanation on, check out this Vlog where we go into detail on all the points and of course, feel free to check out the links below to our courses, you won’t regret it <SHAMELESS PLUG3>. I’m going to go talk to our location director… -Enjoy.
Is it even worth becoming a “web professional” now and what does that even mean?
It can be strange how we categorize our positions and professions. For example, what one person would call a web developer, another would call a web designer. Then there are web programmers and specialties like “front end”, “full stack”, “back end” and “mid-thigh carver” ( I made that last one up, and yes, the last place I came from was the butcher’s…). So then what is a web professional?
And there are other questions, like is web development going to be obsolete with products like WEBFLOW and the like (products that will take away the need to code)?
With these titles and questions swirling around it can be very easy to throw up your hands and say what am I doing?! Is this even worth my time?!
The answer is: yes, yes it is and as far as ‘what is a web professional?’, well, that is a little more complicated…
First off, shameless plug: We offer kick-ass, detailed, and laboriously designed courses that will help to answer this question. So a web professional is kind of all these things combined in different ratios: designer, developer, front end, full stack, braised tenderloin ( I think I’m getting hungry…), etc, etc. Some devs may specialize in specific things (ex: back end or client side whatever), but it’s all in there. Hodge-podge is not necessarily the right word, but it’s the first word that comes to mind…
And how do you, as a web professional, ensure you know all these things or have a passable knowledge/experience with them? You learn. Either from having “been around the block” or by taking our course <another shameless plug, I know!>… But seriously, web development or whatever you want to call yourself is not going anywhere, in fact if the rate at which things are becoming more and more technological keeps growing, we’re going to need more and more devs at all kinds of different strengths and experiences.
Check out the vlog for a way more detailed and in depth explanation of this subject and quick side dig at RUBY… -Enjoy!
Some criteria to consider when selecting a programming language to learn…
We get this question all the time in some form or another; “I really want to be a developer, but what language (programming) should I learn?” Well, let’s jump into it:
1- Consider the Job: The type of coding or kind of programming you want to do. For example do you need to do/want to build an iOS or android app? Web for small businesses? Etc… These decisions will play a role in what language you choose. 2- Consider the Ecosystem around the Language: You don’t necessarily want to jump into a technology that was not yet well enough established. Generally speaking if there’s no support/community for that framework/language, it might not progress or evolve with the “times”… 3- Consider the Job Opportunities Around the Language: Kinda relates to #2, if there’s not a lot of cross-platform support or community base, then generally speaking, you’re going to have a hard time finding a job with a more obscure language… Sometimes the “niche” market pays off but those opportunities are few and far between. 4- Consider the Market Forces: Competition can play a big role in choosing a language. How many other devs will you be competing against? What’s their experience? What is the Language that the majority of the market uses? All these things should at least be considered when you’re choosing a language.
Now that we’ve wound you up tight with anxiety and nervousness for choosing the right language (or failing miserably right out of the gate), let us offer you calming and relaxing idea to soothe you mind… It doesn’t really matter what language you pick… “Most of the modern languages share 80-90% (depending on language) of the same principles and constructs. The syntax or code that you write may be different, but at the end of the day…it’s the underlying architecture that makes the language…” so don’t worry about nailing your choice right outta the gate.
Check out the vlog for a more in depth explanation of how to go about choosing a language. And when in doubt, choose an open platform over a closed one; they tend to win out in the end. Enjoy.
So when we’re writing code, do we prefer the almighty desktop or the versatile laptop? Great question, and one that has two answers:
First, the general answer: It doesn’t matter so long as you do the work in a comfortable and productive environment… And the actual answer: We like laptops. Why? They’re flexible and you can take them anywhere, which means you can work anywhere. And, “these days computers [laptops] are so powerful, that writing code will not even put pressure on a five year old laptop (or desktop); you don’t need much horsepower to write code…”. Of course there are some exceptions (ex: code compiling, etc.), but as a general rule laptops offer way more flexibility and even the slightly older ones still have the horse power to get the job done.
Check out the video for more in depth discussion and the specs on the laptop we’re currently using to write code. Plus stick around til the end of the video to see what is either a beautiful shot of the clouds parting and the sun gently taking back the day…or the beginning of the day the dragons flew in, took over and made us their slaves… all hail CRTHYXSIS: great and powerful lord of the horde!! Enjoy!
Stop playing games, learn to code for the real-world:
Ok guys, let’s separate the fun n’ games from the work. That’s not to say that work can’t be fun and rewarding like a game would be, but I think we can all agree work is work, yeah? Great.
Now that we’re all on same page; competitive coding/programming: that is where you have to write a certain amount of code in a certain period of time, or figure out some little algorithm/mind-teasers of coding or snippets that you have to solve (sometimes while timed), does not necessarily make you a good programmer.
I know, I know where the hell do I get off? But hear me out, this is fun n’ games, that’s all. Since when does being able to do something fast, make you good at it? In fact, I think we can all think of many instances in our lives when the exact opposite was true…
“At the end of the day what makes a professional coder…[they] know how to write clean, reusable code that is decoupled from everything else (decentralized, if you will)…and very readable and maintainable.” “Speed coding…might be good if you’re doing some light scripting maybe for MAYA or some video game or video game processing…and even that is very debatable…” I think we can all agree that it doesn’t matter if you can write code 30, 40 or even 50% faster if the code sucks. Usually you would more than double the actual time spent on edits and corrections…
So here’s the hot take: At the end of the day fun n’ games is fun: we get a little challenge, we get a laugh, we might even make a friend or two and feel embraced by a community, but it’s not serious, it’s not planned or deliberate: it’s not work.
Check out the Video where we go into more detail about this and <Shameless Self-Promotion>, we offer some kick-ass courses on coding/programming that are both fun and deliberate 🙂 Enjoy!
First things first, a kick-ass opening for this vlog with a (literally, for those afraid of heights) breath-taking view of Montreal, and then back into the “studio” to check out my rig (drums), all to a slick tune in the background. Maybe we’ll call this segment, “Weeee, so fly.”
But let’s dive right into it… Should you use JAVA for back end web app development?
A very specific question deserves a very specific answer: “At the end of the day you have to always judge your technology stacks based on both technical implications of the choice and market implications.”
Technology implications: Do you have experience with the language you’re using? Are you comfortable as programmer? “It depends how nerdy you are, if you are very comfortable writing code, you’re very comfortable as a developer and you’ve done web apps before, yeah, JAVA, could be a good choice, but you gotta consider more than just the technical aspects of the language…”
In terms of market implications: “…are there jobs there? Is there a long road ahead for that particular technology stack?” Now, there are plenty of jobs in JAVA but they tend to be in or with larger businesses/ organizations. Even with smaller businesses or freelance work “JAVA would not be my first, second, or third choice…”.
Check out the video for a super detailed answer to this question and the more broad lesson that we’re trying to teach: What can you do Vs. what will the market pay you for. Also, did you find our RUBY diss(es)? Oh, yeah, there might be more than one! Enjoy!
Full transparency: We have a book and we do videos, so we know what we’re talking about having been on both sides of the fence… And of course, our answer is (unsurprisingly) both-ish; kinda like a two pronged attack…
Books are great for referencing material, for example, you need to look something up, you find the page and boom: there it is! As opposed to sometimes having to watch a 15-20 minute video that has great material but it’s buried deep in the vid. You might have to start jumping around on the time bar to find it or it won’t be covered til minute 8 or the 15 minutes, which can be pretty frustrating when time is a factor.
Video on the other hand is great for “…engaging with the material you just learned.” If you’ve been following us for awhile, you know we have online courses that are tailor-made to helping you learn and then put to practice (through questions, exercises, etc.) the things you just learned. While with a book the learning tends to be more passive and in the case of retention, it’s hard to put it down sometimes and start practicing what you just read…
Now we’re not knocking anyone’s learning style, if you can retain and use information you’ve just read in a book, that’s great! We’re just trying to lay out what we think is the best of both worlds and will yield the best results vs. effort. Check out the vid where we go into MAJOR detail. And check out our links at the bottom to our kickass courses: it’s super effective! Enjoy!
Alright we’re going to lightly touch on this and if there’s enough of a public outcry, we’ll gladly do a deep dive but for now let’s skim over client side Vs. server side rendering. YAY!!
Now, full disclosure: It’s better to watch the video than to spend time reading what’s being written. The video is quick articulate and makes good and knowledgeable arguments for sides better than writing this out. But if you still feel like reading on, here’s the (very) skinny…
CLIENT SIDE RENDERING: So when you’re looking at the app/website, the views you render/send out (to the web browser) for the client to see. Generally you want to keep the views pretty simple when it comes to the processing power behind it.
The downside? Not everyone has the same hardware on their computers and may encounter trouble viewing the page (ex: web browsers not up to date, lag, slow load times, etc.)
SERVER SIDE: Does not rely on your viewers having the most up to date web-browser or fastest computer but it does require a lot of server side processing power…
So what’s a dev to do?
Check out our video for answers and opinions. Enjoy!
HTML4 classic formatting tags, vs modern HTML5 interpretation of semantic tags.
HEADS UP: We’re answering what may be considered a beginner’s question so if you’re super busy and you already know the answer to this, feel free to move on. But there’s a little nerd history lesson in it…
So, “what is the difference between strong vs. bold tags, and between EM(emphasized) vs. italic tags? To me, they look the same on a web page. What is the purpose of distinguishing between the two?”
Great question. Simple answer: it’s semantics NOW… “You can use either/or today; it doesn’t make a difference.”
Historically: “when HTML was first invented there was no CSS, so they needed tags (a set of html tags), to allow web pages builders to add some styling to the page. ie: add italics, make certain texts bold, insert images, etc. So the early browser-makers … created a set of tags that were display tags: they allowed to change the look of things on the pages.”
As things evolved and HTML5 came along, the powers that be decided to give semantic meaning to the tags instead of having programmers go back and update/correct their previous work. Now, that being said there is absolute use in these semantic tags; for example those with accessibility issues like the seeing impaired will have a “reader” talk the page out and in that case, the reader will interpret paragraph tags, heading/footer tags,etc and it may become pretty useful.
Another use would be to target a very special audience or for very specific web application needs…but that’s another video…
Speaking of videos, please check this one out for a more in-depth history lesson with way more charisma than the typed word.
Also -shameless plug- Our web development course teaches you the infrastructure / history of these tags and how they operate. We like to go above and beyond -Check it out. Plus at the end of the video, some sweet summer heat and beach!! Enjoy!
Hard to learn, easy to write … but slow to code with
ALSO: It’s dog-slow at run time when writing desktop applications (never mind mobile apps).
So there you have it, from a guy that loves JAVA. It’s super verbose and heavily detailed in the writing (which also means less errors because you’re being explicit), and that writing code takes much more time, much more time means much more work and money/cost: “I wouldn’t do it.”
Check out the video for a more in-depth explanation PLUS what’s coming up with us with STUDIOWEB and other fundamental stuff we’re working on; super exciting stuff!