Hardware hacking is a way of life here at Hackaday. We celebrate projects every day with hot glue, duct tape, upcycled parts, and everything in between. It’s open season to hack hardware. Out in the world, for some reason software doesn’t receive the same laissez-faire treatment. “Too many lines in that file” “bad habits” “bad variable names” the comments often rain down. Even the unsafest silliest of projects isn’t safe. Building a robot to shine lasers into a person’s eyes? Better make sure you have less than 500 lines of code per file!
Why is this? What makes readers and commenters hold software to a higher standard than the hardware it happens to be running on? The reasons are many and varied, and it’s a trend I’d like to see stopped.
Software engineering is a relatively young and fast evolving science. Every few months there is a new hot language on the block, with forums, user groups, and articles galore. Even the way software engineers work is constantly changing. Waterfall to agile, V-Model, Spiral model. Even software design methodologies change — from pseudo code to UML to test driven development, the list goes on and on.
Terms like “clean code” get thrown around. It’s not good enough to have software that works. Software must be well commented, maintainable, elegant, and of course, follow the best coding practices. Most of these are good ideas… in the work environment. Work is what a lot of this boils down to. Software engineers have to stay up to date with new trends to be employable.
There is a certain amount of “born again” mentality among professional software developers. Coders generally hate having change forced upon them. But when they find a tool or system they like, they embrace it both professionally, and in their personal projects. Then they’re out spreading the word of this new method or tool; on Reddit, in forums, to anyone who will listen. The classic example of this is, of course, editors like the vi vs emacs debate.
Code Tyrants
This evangelism is where many of the comments come from. Many experienced coders truly believe if you’re not doing things their way, you’re doing it the wrong way. And of course, if someone is wrong on the internet they must be corrected. I like to call these folks Code Tyrants. It doesn’t matter your skill level, background, if you’re coding for work, or for a fun project. They’re going to show you their way, and are willing to debate the topic for hours with anyone else who jumps in.
Don’t be a code tyrant. There are plenty of places on the internet to debate tools and techniques.
Someone who is just learning to program probably doesn’t need to know all the coolest tricks. In fact, the newest stuff can be detrimental. A new coder learning to program C/C++ on embedded systems probably won’t be well served by being taught C++11’s smart pointers. I’ve seen coders complain that someone didn’t use ternarys when they could have. Ternary operators are a pet peeve of mine.
this
if (foo > bar)
{
output = fizz;
}
else
{
output = buzz;
}
vs this
output = foo > bar ? fizz : buzz;
Anyone can read the first snippet. It’s practically English. While shorter, second snippet isn’t readable to a new coder. The compiler doesn’t give a damn, you’re going to get the same assembly output either way.
Learning to code
Many accomplished programmers have forgotten what it is like learning to program. Tutorials that don’t quite make sense, cryptic error messages, and question forum threads that never get answered.
Arduino tries to make things a bit easier. But at its core, it’s just C mixed with a bit of C++ (one of the hardest languages to jump into). Have an error in your program? Arduino’s IDE will just throw up the error text from avr-gcc. This is not exactly newbie friendly.
What does a neophyte programmer do when they get stuck? The same thing the pros do. Hop onto Google and start searching. This is where things can go from bad to worse. For one reason or another, StackOverflow is always in the top 10 results of coding searches. As a resource, it is a bit of a double-edged sword. There is a lot of good information there. However, the code tyrants have been busy, with arguing, nitpicking, and answers may contain outdated, and plain old bad information. More than a few bloggers have lamented this. When Randal Munroe makes StackOverflow answers an example a for an XKCD comic, you know you’re in trouble. The stack sort has been implemented, you can check it out here. Experienced coders can separate the signal from the noise. But someone new is going to have a rough go of it.
Be a Mentor
So what is the solution to all of this? I think the amateur radio folks have a good system for it already. Volunteer Mentors, called “Elmers” help enthusiasts on their journey from neophyte to journeyman. According to the ARRL, mentoring begins with the local club. For us, these clubs are hackerspaces and makerspaces. The folks volunteering time at these spaces already are doing a great job helping people learn both software and hardware. I propose they take it one step further. Try to find a core group of folks who are willing to become mentors — to take responsibility for a few students. That means fielding their questions, and guiding them as they run into trouble learning to code. Not just once or twice a week at open hack night. Give them your email and field questions as they come in.
Being a mentor doesn’t mean teaching from the ground up. There are hundreds of tutorials, videos, and books out there. Some are good, others not so much. A good mentor should be able to cut through the weeds and recommend a few good ones.
Not everyone is physically near a hackerspace though. For them the only option is online resources. There are subreddits, and forums, and our own Hackaday.io, which has an excellent group of folks in the hack chat channel.
Learning coding from a mentor is a rewarding experience both for the student and the mentor themselves. The hope is that students will go on to become code mentors, helping the next generation go from code neophyte to hardware hacking code master.
“Learning coding from a mentor is a rewarding experience both for the student and the mentor themselves. The hope is that students will go on to become code mentors, helping the next generation go from code neophyte to hardware hacking code master.”
And then there’s how a lot learned it. Coded while young in our spare time (“Hello World”) Found it interesting, decided to make a career out of it. Go to school to learn how to do something better. Graduate, and go straight into a company where you learn their ways of doing things.
Many of us learned before the internet age. Answers came in the form of books, or conversations with friends. The internet introduces a whole set of new ways to learn programming – both good and bad.
I bought a book on programming the Sharp Pocket PC (sold by Radio Shack) and modified the programs to run on my ZX-81. Book and magazines (Sync) were the main source of info, especially if your friends had different brands of PCs (early 80’s). Once I got a PC, then most of my friends were using GW-Basic on DOS. That made “tech support” easier, at least until Windows became established.
Beagle Bros FTW!!!
emacs sucks…. Just kidding. Let the flame war continue.
Oh, geez – but one must ask – if the history of unix commands is short abbreviations of their names doesn’t that mean vi is really vile ? LOL
First came ed, which was a line-oriented editor (ed is short for edit).
Then came ex, which was an extended version of ed. (ex is short for ed extended). Among other features of ed was a “visual mode”, which showed a full screen of the file being edited, rather than being purely line-oriented. It was still line oriented, but you could see what you were doing.
Then came vi, which was essentially the visual mode of ex. (vi is short for visual)
First came TECO, which was a “Tape Editor and Corrector”, and was designed to edit paper tape.
Then screen mode was added to teco, so you could see the results of a teco command as you worked.
Then a macro system was added to teco, so you could bind complex teco commands to a single key press.
Then an “extended macro” package was written, called “emacs”, which allowed you to use TECO as if it were a full-screen editor.
Then the emacs macros were divorced from TECO and written for a new lisp-based backend.
Eight Megs And Constantly Swapping…
It’s 2017, 8 MB of RAM costs five cents. Just keep adding RAM until your system stops swapping. (My Eclipse is at 690 MB at the moment, no swapping, 16GB total in the machine.)
Yep… 8MB RAM didn’t cost 5 cents when EMACS earned that title.
Most of my machines have at least 1GB RAM these days, including the teenage laptop I am typing this reply on. Most production machines have 8GB… even then, I shudder at 690MB. I’ll stick to
qvimthanks. :-)Don’t fall into the trap of specialising in one language or framework.
It’s the algorithm and solving the problem that’s important.
Use the language thats best suited to solve the problem.
Be willing to switch languages. Don’t be afraid of having to use reference material to check syntax or usage. Being able to type code from memory doesn’t make someone a good programmer.
Maybe prototype in one and use another for the finished product.
Each language or framework has its own benefits and compromises.
Switching between them will often give you insights into solving the problem as your made to look at the problem in a different way.
And another thing: Use the language frameworks where built in/for, trying to make a framework work in your favorite language instead is a never ending and ultimately futile process involving much more plumbing and adaption than actual work.
“You wouldn’t use a hammer to tighten a bolt, or a wrench to pound in a nail, would you?”
Use the right tool for the job :D
I have, in fact, used a wrench to pound in a nail before.
And I have used a hammer (and cold chisel) to tighten a bolt.
Screwdrivers for chisels…..
If all you have is a hammer, everything looks like a nail.
And if you can’t fix it with a hammer, it must be an electrical fault.
I once saw something resembling a car starter motor that had an electrical fault like that! It obviously responded very positively to the hammer treatment for a very long time. It was also obvious that thereafter it did not respond at all to a very long hammer treatment.
You haven’t seen the guys that I work with then. If it can’t be welded or duct taped, to them it is not repairable.
Lumia 950s for nails
This is quite interesting… two days ago I went in for an interview for a PLC programmer position.
When I got there, the head of Automation controls asked me to solve a 13 question logic test which consisted of programming functions such as Add, Subtract, compare, modulo, etc… assuming that all variables are unsigned integers and there would be no if, return, exit, or break instructions… (basically writing Assembly for a 16F84 PIC with its 31 instructions or so).
In the end he explained that the company hires all types of programmers (PLCs, embedded devices up to servers and web) and they find that by focusing in a specific language they aren’t really assessing the programming capability of someone but more of his/her experience in that language. Having something that is just pure logic with an extremely limited set of instructions is a far better assessment of the person’s programming skills.
I like that solution to the programmer test. There is an ‘if’ in that instruction set you mentioned though. Consider linear interpolation: a * (1 – t) + b * t. An ‘if’ statement is simply this equation with t = 0 or t = 1. Coercing values larger than 1 to be 1 depends on which instructions but there are a load of options there for arithmetic, binary logic and combinations of the two. These are the sorts of things I would look for with such a test. A good understanding of the fundamentals that crappy programmers tend to ignore.
Of course I was only motivated to learn this stuff to have control flow in a language which traded binary operations for comprehensive arithmetic and algebra operations. Eventually I did dive deep into binary logic without such a reason and discovered many other ways to abuse arithmetic to perform binary operations as well as the other way around. It’s in learning this sort of stuff that you actually learn programming instead of a language.
I would like to take a test like this. Do you know of any resources that provide similar questions?
I agree that mentoring is a rewarding experience for the mentor. My friend’s kid, now an aerospace engineering student at Purdue, was really born with the knack. I spend many years helping him with his little projects, and arduino coding, and that was probably one of the more useful things I have done in my life.
I disagree with the idea statement that I’d be a good person to recommend an intro to programming tutorial, though. I’ve been programming since 1977 on my Dad’s TRS-80, so I don’t have a lot of relevant tutorial experience (although the BASIC book that came with the Trash 80 was really excellent to teach a 12 year old to program).
Wow! Still programming a TRS-80 after all this time? That’s amazing!
BASIC is a really great language for entertaining beginners and that is vitally important because if there is noting that it *interesting* about coding then a beginner will give up.
Apart from that, old line numbered BASIC is about the worse teacher of bad coding habits because of the two letter variable names and the nameless line (numbers).
I’ve meet a few people that would code a hello world program with 20 templated classes. I’m pretty sure they were the best programmers in the world as their code had to be…
I’m currently trying to beat^Wmentor into people that less code is better, and found the following to console myself with as I wait for the build to take 15min (vs 30sec on my previous similar project) compiling…
http://www.jbox.dk/quotations.htm
* Compiling speed is not everything.
* less code is not better or worse. Lets return to readability and maintainability, also debugging aspects of code. how would you say it is better?
when less code is better? – when it increases performance, effectiveness.
but i might mistaken to understand what you are saying, too much grammatical mistakes : ). I am not native speaker. what this “trying to beat^Wmentor into people”, ” and found the following to console myself” means…
Code has bugs. More code has more bugs.
More code takes longer, requiring a processor arms race, and consuming more current.
In our chips, current consumption is important, as is silicon area.
Readability and maintainability is a given in any professional environment.
Your comment makes my eyes bleed. Do you even know what you’re talking about?
> I am not native speaker. what this “trying to beat^Wmentor into people”, ” and found the following to console myself” means…
The first one is a joke from old computer systems, ^W means “delete previous word”. So you can read it as “trying to beat – no, not beat… mentor – into people”.
“found the following to console myself” means “I find this page helps me to feel better” (referring to the link at the end).
(What’s your native language?)
Up to a certain point, I see plenty of people trying to make something work with _too little_ code, making it virtually impossible to understand and maintain the code afterwards.
One of the benefits of too little code is, you don’t mind starting over when it doesn’t work, obviously if you’d used enough code, you could just fix it.
Sometimes the long way round is the quickest.
I am always finding that those compressed fragments can be terrifying. They are so indecipherable that you are left wondering if you are getting rid of something important. I tend to comment and hope that past me who wrote said super fragment thought ahead to present me and it’s not a trap.
FizzBuzz enterprise edition http://www.fizzbuzz.enterprises
FizzBuzz Python edition:
for a in range(1, 101):
b = print
for c in range(3, 6, 2):
if not a % c:
print(“Fizz” if c == range(3, 6, 2)[0] else “Buzz”, end = “”)
b = lambda _, end: None
b(a, end = “”); print()
Hmm… some (probably dirty) WP code removed all the tabs.
def a_function():
print ("Did someone forget the code tags?")
# Or do they not work?
Okay, code doesn’t work. How about pre?
def test(): print('Indented?')output = fizz if foo > bar else buzz
I think this is readable even by non-programmers. That is standard Python code.
I don’t get the sense that the endless fad chasing in software development will ever end but it is the most loathesome part of the job for sure. For what it is worth I generally write C and assembly and let the fad chasers run themselves tagged over there, but I am lucky in that nobody is dumb enough to ask for devce drivers in Java so I can be fairly safe in my domain-specific niche and mentoring has been of enormous importance to me because a lot of people didn’t learn any system programming in school and both from a philosophical standpoint (because I feel this is key knowledge) and from a practical standpoint (so there’s someone to cover when I take a vacation or sick day).
From what I can tell the fad chasing is mostly about two things:
1) The search for the elusive “do what I mean” command.
2) Getting more work out of the same programmers via relentless whip cracking and cult-like development manifestos.
Nuts to that!
I don’t think they teach systems programming to any acceptable level these days.
I’ve had to show two people so far how to use the bitwise operators to extract fields out of a byte or word.
Long / short form makes no difference to a programmer also. If anyone would demand to write the longer forms in sense it is “more readable” that would mean bullying. For janitor yes, but not for programmer and to continue argument, to learn that syntax is like 5 minutes of efforts.
This whole thing of attempting to create more readable code sometimes can be pain in an ass, specially when you working with 5 – 15 coders…yes following clean code principals and other programming rules you would produce way better code, but strongly disagree with a point that a code should be adapted for beginners level of understanding. That is blasphemy.
Well mentoring against “tyranny” has some points, but tyranny arises, imagine when you work with 20 coders who are like child’s always leaving a mess and you can’t just go mentoring and explaining every step to that amount of people, so some strict rules must be applied. I seen in a lot of companies they do even restrict certain features of langues to be used, in argument that noobs would not understand the code. That is a real tyranny.
And teaching to code and mentoring are two different things by the way.
Note that this article specifically isn’t about the workplace, but about the importance of not treating random places on the itnernet as though they were your workplace. Imagine people making wooden furniture in their back yard only for someone to pull over and start going “Woah, woah, woah! Would you build a skyscraper like that?”.
In my experience at university, programming is the only engineering subject where instructors will openly mock students and treat them like they’re stupid for making mistakes or needing extra help.
well just ignore that : ). At university it was similar to me, until instructors found out that all course students code is written by me : D
You realize you’re basically saying “just don’t have feelings,” right? That’s not exactly useful advice.
There *were* survivors!
Supposedly some legislators were trying to define “pornography”.
Finally one said, “Maybe I can’t define it, but I know what it is when I see it!”
And that’s how I feel about bad code. I know bad code when I see it.
For the beginning programmer, the only concern is often, “does it work”, and everything else is swept under the rug.
I would argue for a sense of pride and craftsmanship. And don’t forget, you can write bad code in any language,
using any paradigm (or editor). Don’t be afraid of white space. Don’t go crazy trying to be terse.
I don’t think the pragmatic ‘does it work’ test is complete without the caveat ‘will other people be able to use/modify my code without me’ also being true.
Far better in many cases to use inefficient code that is easily understood than optimum code that is indecipherable.
I totally agree. I used to be an efficiency freak — it is absolutely the wrong way to focus your mind except in a few rare cases. Aiming for clarity and readability is by far the better mental state to cultivate. You will thank yourself when you revisit your own code years later.
Amen!
+1
Just like every other branch of engineering/manufacturing/writing/art: prototype first, make sure it works, then revise to make it easier for others to use. In other words: Make it work THEN make it pretty.
I can appreciate that but even with the goal of first to function, sometimes you can see that the way you’re doing it will cause issues later even if you don’t know a better way to do it.
Sometimes forging ahead with an inefficient method paints you into a corner later. Barring those obvious exceptions, just getting your proof of concept out there is certainly not wrong. In those instances it may be more beneficial to stop and slog through the problem now rather than putting it off.
I’ve had the opposite experience. When you’re trying to make something work by bodging it together, it won’t, and then you yourself won’t understand why it doesn’t work because it’s a mess. Then you start again, do it all neat and nice, methodically the long way around, and it just works.
But that only happens after the first bodge fails to function. If you try to be neat the first time, it will turn into a hack that perhaps has a higher chance to work, but nevertheless has parts that should not see the light of day and have to be re-done eventually anyhow.
My pet dislike is Dependency Injection / Inversion-of-Control code. It is *supposed* to make it easier (for the author) to change inputs to the logic, but it’s a complete nightmare maze of twisted logic for anyone else to figure out (that has included me) what and where the control flow is going so it’s self-defeating.
And yet when Joel Spolsky pointed that out, he was hounded down by bleeding-edge know-it-alls.
Ternary operator readability ain’t nothing compared to IoC!
Maybe a good standard is if you cant figure out your own code after not seeing it for 6 months, that it is probably hundreds of lines of spaghetti logic (ie, not that good).
After all, we mock hardware designers who design cars where you have to jack it up and remove a tire to access a spark plug or remove an oil filter.
This reminds me of something I always found troublesome with adafruit’s tutorials and sample code. For all the wonderful quality of the work they do and all the straightforward direction and explanation of things in their tutorials, it seemed to me their sample code was newbie-unreadable Engineer-ese. It was always “output = foo > bar ? fizz : buzz;” as far as the eye can see, when something far more readable to newcomers would compile exactly the same and be much easier to learn from.
Readable means more typing, and for those where typing is a means to an end, and not the end itself, that can be important.
Copy & paste “hackers” aren’t impacted by extra verbosity. But those that want to learn will be scared by cryptic code. Is that much effort to type 4 extra curly brackets and an “else”?
If you’re really lazy you can even drop the curlies and put everything on one line. Still much more comprehendable to eginners and pros.
It’s not exactly hard to learn how the question mark operator works. You do it once and you know it… I really don’t see a problem here. It’s a five minute thing and then it’s a non-issue, and you are a better programmer for having learnt it.
There is a reason why experienced programmers use that stuff. There is a reason why we like good variable naming (hint: put the units in the name, e.g. battery_mv for battery millivolts). Experience has taught us that not making the small effort now just creates technical debt, which has to be paid off later when debugging or trying to modify code.
It’s like a rat’s nest on a breadboard. Yeah, it works, but if you find some rare fault condition or need to modify it you have to pay the technical debt you built up when you threw it together in the first place.
Not only what MoJo says but also using ‘?:’ and ‘??’ in the middle of an equation does improve readability. I know there are at least 5 algorithms in my personal library that make sense, even to a beginner as long as they are decent with math but if I split them up to replace those operators with ‘if-else’ blocks. Well the understanding of what that algorithm does changes.
I got a good degree of amusement out of people claiming it wasn’t easy enough or too cryptic at some point when I got fed up with it. Was working on a C# project, writing part of a generalized input system to support arbitrary key bindings. Removed all the properties and replaced their functionality by overriding the ‘+’ and ‘-‘ operators. So a keybinding became: someBinding = Keys.B + DoThatAction() or someBinding = Mouse.MoveX + Mouse.MoveY+ Keys.Shift + DoThatAction(). I laughed maniacally while saying I think it’s elegantly simple now as the complainer rolled back those changes.
Quote: “It’s not exactly hard to learn how the question mark operator works. … There is a reason why experienced programmers use that stuff”
Well I am an experienced programmer and I don’t use less common operators like this because I program in many different languages and as you say – you have to *learn* how to use this operator … or in other words it is NOT intuitive.
When I am using a new language I have to wonder at times what the primitives in the new language are without having to stop and google. Most of them can be guesses – is it instr() or substr() or strstr() – not hard to guess at but weird operators like this are only used by programmers that stick to one language or a small number of languages.
The second part of your post argues for readability and I agree with all of that but at the same time I believe that this operator is less readable than a more traditional syntax that is used in most other languages.
Hazardous subject.
Anyone looking to mentor others should be avoided till they finish dealing with their own grandeur. It’s better to just ask your peers for ideas and have open discussion together.
Of every 10 mentors, 9 are pretenders. These are not the droids you are looking for.
Mentors learned by having already done everything wrong once, and know they aren’t done yet.
This guy gets it!
+1
“Ternary operators are a pet peeve of mine.”
They are one of mine as well, but we sit on different sides of the fence. Your “long” example takes 8 lines of my screen space when you could be using one, that is fairly readable (I usually add parentheses on the condition to make it clear).
Readability and screen space are both important. And really, if you can’t parse x = (a > b) ? y : z; faster than the long form, you need to read more code.
Short form is NOT readable for someone, who doesn’t know every detail of language, in other words a newbie. And reading obfuscating code won’t help them at all. Clearly you missed the point of the article…
“who doesn’t know every detail of language”
is one of the few core operators of C an optional detail of knowing the language?
You can prefer not to use it, but knowing it exists is important if you’re going to interact with any code written by anyone else at all.
You stumble upon a template declaration and can’t understand what is going on? That is fine. But if you come across your first ternary operator, you should look it up and figure out how that works. If you can’t read a ternary operator shortly after you learn what it is, you should keep very far away from other people’s C code. And never look at any Perl code, ever.
You are still missing the point. Please be kind and pull your head out of your anus and then consider following statements:
1. Newbie might not know, what ternary operator is, because he didn’t have that in his tutorial.
2. Newbie therefore seeing “output = foo > bar ? fizz : buzz;” won’t know, what it is.
3. How newbie can find proper term to Google for to understand this piece of code? Googling code itself won’t help him, if it’s specific to one source file.
There is this new, cool feature called “scrolling” or something, that lets you move the code up and down to show more of it on your screen. Also there is this other cool feature of your brain called short-term memory that lets you remember what you saw before using scrolling.
<sigh>
1. Time to learn, he won’t know what **x means the first time he sees it either
2. Agreed
3. You don’t search for a chunk of the code you don’t understand, you search for the pieces you don’t understand. http://lmgtfy.com/?q=%3A%3F
Let’s make it clear. What matters is readability first, then maintainability and minor considerations of style last (assuming your code works at all, of course). I’m saying the ternary operator is a BASIC, FUNDAMENTAL part of C and other languages that support it, and that trivial uses of it for stuff like that conditional assignment are more readable than expanding the assignment to separate lines and the conditional to yet another, reducing the scope of code you can read with a single glance.
And to make it clearer: When you write code, you should write it according to the purpose it’s going to serve. When you write code that’s supposed to be run, your focus should be on maintainability and doing the task efficiently. If your code is supposed to be read as an example, it should focus solely on readability, and you should only use the least amount of features of the language as needed.
When you’re writing real code, you should use whatever features of the language you’re using make sense at the moment, and will keep the code readable TO SOMEONE COMPETENT ENOUGH TO MAINTAIN IT, not to a random person on the street. If I’m writing the core of a timing-sensitive loop and I need to get down to assembly to make it do what it needs, I’m going to do that and I expect any fool who tries to mess with it to be competent enough for the job.
And I’m done with this thread :-P
Newbie should go back to school and hit the books.
Haha, I was going to mention Perl. That is a frustrating language to parse when I used it. (After a decade of disuse I’m sure it’s nigh impossible).
I remember writing stuff like:
x = or die
Indeed, you miss the point. Don’t fear white space. Don’t aim to be terse for terseness sake. I would pick the if/else code over the ternary operator any day. You wouldn’t believe how much code I have written, and I can parse the long form at a glance and just groan when I see ternary operators.
Readability first. It’s not fear of white space, is that white space is a terrible use of screen real state.
Lines of code tend to be short (unless you are abusing them), so you are already constrained in one dimension. If you keep wasting the other one with meaningless empty lines (it’s perfectly fine to chop up code clocks with an empty line, but if you do that every couple of lines, the effect is wasted) and spreading the actual content thin, you end up with functions that do very simple things and still require multiple screens to be read.
If you can get a clean, readable function to fit in a single screen, you did a pretty good job. It gets considerable harder if a single conditional assignment takes 8 bloody lines.
if (foo > bar) output = fizz; else output = buzz;
But seriously, stop coding on your phone.
There are cases in which ternaries are the right fit for the task, and they are certainly not meant as substitute for conditional blocks or vice versa, although you can write conditional blocks using ternaries (but you shouldn’t). Generally, if there are side effects involved or you don’t need to get a single value out of decision block, don’t use ternaries.
Now, when do you want use them?
Sometimes you need an anonymous conditional assignment or conditionally selected argument of a function call. The alternative, (which is a pet peeve of mine) is to place separate, complete, mostly redundant function calls inside if-else (or worse, if-else if-else if-…-else) conditional blocks.
Compiler may not optimise out slightly different function calls and back end will generate boilerplate placement of arguments on stack and handling return values for each instance of function call in each block. It may be marginally faster code, but it generates greater executables, which may be bad for you if you are doing embedded programming.
Another, better alternative to multiple conditional calls is placing assignments to explicit temporary variables (used as arguments in a single function call after the block of decisions), but it means that whoever reads the code afterwards must check the “life story” of each such variable to be sure they understand what is going on. To many identifiers (e.g. explicit temporary variables) makes code hard to inspect.
“if (foo > bar) output = fizz; else output = buzz;”
That violates the Don’t Repeat Yourself principle.
When mentoring, it’s best not to teach bad habits.
Instead, teach your mentee about the ternary operator, where it should be used, and where it should not.
+1 for maximising use of screen space. I regularly with on systems with millions of lines of code, and being able see as much as possible on a single screen is key. Visual Studio even has a syntactic line compression plug in that compresses blank lines, hanging braces, etc just a little so you can view more code.
Having said what I did about not being afraid of white space, I have to agree with what is being said here. You need to be able to see a certain “chunk” of code all at once to be able to grasp it, and that means having it on one screen. I only use blank lines myself to separate “major thoughts” or code sections. There is nothing good though about using semicolons to string statements on one line though.
Just get a larger screen.
That was my *fix* to.
I now use a 37″ (94cm) monitor. It also has lots of other benefits like using a macro camera and zooming on screen.
Thanks for writing this. As someone who programs predominately as a hobby I seek a lot of answers from Stackoverflow, but am often afraid of asking questions because of the almost toxic responses that don’t even attempt to answer the question at hand. That and people who insist on the ‘Pythonic’ way of making programs in as few lines as possible to the point where they are unreadable to neophytes like myself.
This is something Raymond Hettinger harps on quite frequently. He gives an interesting talk on PEP 8 and you can find his talks on other things but the ‘Beyond PEP 8’ talk in particular addresses it.
Yes. My employers have required me to learn Python and in the early days I asked a question on Stack Overflow. I was told off for capitalising (CamelCasing) my variable names in the wrong way. Apparently this is “not the Python way”. Fsck that.
Hi,I am 15 and I am French.I am a beginner in code and I search a French Mentor for Html or Python. Please contact me if you are interested.
I give up on learning to code every attempt I make, mostly because I have to look literally everything up at every step, even with tutorials, and a lot of the resources I found were not easily parse-able or took too long to do so. I don’t think I’ll ever get it and I’ve stopped even trying.
Churchills famous speech – “never give up!”
Nobody said it is easy, and there is a certain critical mass you have to get into your head to get going, but then you take flight.
Learning to code is a time investment. Every minute you invest will pay off in the long run and it becomes easier as time goes on.
If you find a language isn’t appealing to you then give up *on that language* for the time being and try a different language.
There are a gazillion languages out there so find the right one *for you* to get started with. After that time investment things will be far easier and you can move back to the languages you originally found difficult.
The crux of the matter : “Anyone can read the first snippet”. In my not so humble opinion, after more than 35 years in the software trenches, that’s what defines “good” code. I’ve worked on code that was written by a multi-lingual Swiss company with French, Italian and German variable and function names. The horror!
Had similar issue at previous contract where the team was all EEs except myself having a mix of English, Spanish, and French native speakers. Quietly and whimsically suggested Klingon as the universal language for comments and naming. The ‘manager’ put it in the project standards(?!?!). It was rather interesting watching the customer at the first review.
This is wandering off of the mentoring topic. I have been coding for at least 40 years. I would be happy to mentor somebody, but folks aren’t lining up to be mentored. I could just be me, but I don’t think people are lining up to be mentored anywhere. Most eager young coders are like I was, they think they know it all and just want anyone who makes suggestions to get the heck out of the way.
So let’s talk about coding style. The beginning “coder” (for lack of a better word) is at first just happy anything works. Then they are pleased with themselves when they write a big program. Then maybe they start thinking about coding style. As has been said, the best thing to aim for is clarity. But I want to make a recommendation. Go find (do a search on “torvalds coding style”) a document written by Linux Torvalds on C coding style. I am no linus fanboy, but I was quite pleased when I found and read this document. I am pretty set in my ways, and was surprised to find that he as arrived at many of the same guidlines that I have.
At least think about coding style if you are serious about this.
The school of hard knocks has many pupils, but few graduates.
Wow. I’m surprised at how completely I disagree with most of Torvalds’ points.
Brains are very well distributed in the world. Everyone thinks he has more than the other person :)
The problem is due to the type of personality that coding attracts. In my experience (25 years) most of us are a little further along the Aspergers spectrum than the general public.
So true. One of the reasons I have always refused any role in project management. I’d rather herd cats.
I’m more ADHD, so juggling multiple projects seems natural to me. Might explain my PMP cert.
– but cat herding is a perfect analogy.
I’m very laissez-faire about hacky hardware, especially in hobby projects, because I know from experience how large the gap can be between a good idea and a good physical realization of that idea. I certainly don’t have the skills to build a sophisticated enclosure from scratch, let alone something with moving parts. My own projects rely on a lot more gaffer tape and hot glue than I’d like.
With code, the distance between “good idea” and “good execution” is (or at least can be) much smaller, and closing the gap often doesn’t require specialized equipment or expert knowledge, just practice thinking clearly and thoroughly. I don’t think coders should be at each other’s throats about syntax, non-critical inefficiency, or “being Pythonic” (a pet peeve), but I see a lot of value in comments that point out how unclear thinking or poor organization are hampering a piece of code. That’s part of mentoring, but it doesn’t have to arrive in a mentor relationship — I see a lot of very useful comments of that type on Stack Overflow, actually.
Even a hobby project can benefit from clear code (which is not the same as “clean” code), and it can be a lot easier to get there than, say, learning how to design and build strong mechanical parts.
+10 to that. Clear code is easy to read. When you are tired and chasing that elusive bug, it can do all of the diference.
Also, software is easy to fix. With hardware, you probably doesn´t have many of the same chip, or enough pcbs, to go back and correct some mistake if the thing looks like a train wreck. In software, you can just delete the ugly lines and write them again.
“the thing looks like a train wreck”
Yeah no kidding. Usually when my projects get to this stage it’s because everything looked neat and tidy, then I realized I needed one last piece of hardware (electrical or mechanical) to make it all work, and the series of hacks required to fit in that one piece ends up making the whole thing look like it was attacked by a weasel with a screwdriver.
You can tell a bad/unsafe mechanical design by looking at it, or giving it a bit of a shake and seeing if stuff starts to fall out. The tangible physical realities of real life apply, such that you won’t step on a shaky ladder with full confidence that it won’t fail, because you feel the wobble in your feet.
It doesn’t work like that with software. The problems are obscure, and the failure mode is sudden death, and you can’t see why it happened or how to avoid such in the future because you’re not a programmer and even if you saw the source code you wouldn’t understand it.
So it’s paramount to keep the standards high at the source so the users can trust in the quality of the work.
Or, you could draw parallels from cowboy coding to things like electrical wiring. I’m sure it’s perfectly workable to pull all your wiring in the same color because you know what each of them are.
Then again, I knew a guy who burned down his car because he tried to wire a new radio in and used only red wire for the power cables.
I heard of an electrical contractor at a defence base that used a single spool of purple wire for everything.
So yes, the cowboys are numerous.
When we built our house in the uk the wire colours were changing fron red, black and green to brown, blue yellow/green, consequentially red and black wire was dirt cheap, but red was in plentiful supply so I used red, everywhere, now 20 years later it’s a complete mystery what any of them do, oh and it’s all 2.5mm even the lighting.
Sadly my code is similar, a complete mystery to me now.
Medium form:
1 if (foo > bar) output = fizz;
2 else output = buzz;
2 lines instead of 1 or 8.
I don’t like a large number of lines with just { or } on them.
I never dangle an opening brace. I always dangle a closing brace — unless it is immediately followed by an else. But that’s just me. This isn’t code golf where you win by minimizing the number of lines. The goal is clarity.
I recommended reading the Style Guide by Linux Torvalds, and I will mention it again. You should read it, not that you should necessarily agree with everything (or anything), but so you should at least think about everything and have your own good reasons for doing what you do. That being said, read the essay, but don’t look at the linux code base expecting a sterling example of clarity and good coding.
18 years ago read a book on C. Someone stole that book I still remember who you are COREY
There’s something worse than strange coding: strange naming. Why is a single board computer called Raspberry? What’s an AnanasStepper??? I don’t think many people, especially newbies, understand these names.
(Full disclosure: I’m not an exception to this and I give nonsensical names to my stuff too, often referring to brands and trends, like FidgetUI, BURTON (Basic Universal Remote for TVs and Other Non-IoT stuff), or Pineapple Pen Patcher.)
What’s worse, “Raspberry” or “ARM board 33721b”? A literal description isn’t necessarily very useful as a product name – distinctiveness is far more important. It’s when you name a *variable* “Raspberry” that you’re due a paddlin’.
Yes, but anyone should be able to understand what the thing is from its name. “Raspberry” is not going to tell anyone it’s a single board computer (it became very popular and lots of people know it, but that rarely happens to hobbyist projects). This applies to my names too: can you tell what a “BURTON” is?
More explicative names like AnanasStepper and FidgetUI are better: you can easily understand that FidgetUI is a library for user interfaces and the AnanasStepper is a motor controller.
Unless it’s used for referring to a pineapple crushing machine.
I don’t have a problem with naming of products, like Raspberry Pi, Arduino, BeagleBone, etc. What I have a problem with is cute names for add-on products. I’ve heard the terms “cape”, “shield”, “mezzanine board”, and “daughterboard” all used. But why should I be surprised that an Arduino developer would call an extension board a “shield”, when they call programs “sketches”?
We have enough jargon already without making up new redundant names.
Only if a quick trip to google could clear up the function of a weird piece of code the same way it can clear up the question of “what the heck is a RaspberryPi?” would I then believe strange naming is *worse* than strange coding.
Don’t start coding in NodeJS then… Mocha, Chai, Bunyan… etc. Care to guess what any of those are?
I’m so happy that the ‘detailed long code’ vs ‘obscure one liner’ thing was brought up. I’ve been coding for a while now but I most certainly have not forgotten what it was like first starting out. On one hand the magical one liners that I’d come across were very interesting but I would spend forever trying to wrap my head around it and just wishing it was broken out a little because I refuse to recycle code that I completely don’t understand what it’s doing. Even if it does what I want.
Especially in the context of StackOverflow, if you’re posting there, you’re aim is to help someone out and every other person who comes across it. Drop the pride of being a one liner wizard, take a second to add a comment and detail what each/some pieces are doing for ALL who might pass by. You can always provide an alternative answer that is the one liner if you have zero humility. Don’t get me wrong, if you can reduce 20 lines of code to 3, do it. Just don’t reduce 3-5 lines into 1 and claim to be helping.
Also, am I the only one who thinks referencing variables in for loops as single letters is annoying? You can write code that almost reads like english if you spend a little bit of time on naming your variables what they actually relate to. As opposed to, for i in e: enumerate(x).
Loops are suppose to be short, and the counter variable not used outside of the loop, so there’s no point in using long form names. It should be visible at a glance where i or x are defined and what they refer to, and so using the short names simply make the rest of the code more readable by being immediately obvious which variable is variable comes from outside the loop and which one is “local”.
You are the only one. Things like indexing variables in loops are best as just a single meaningless variable. By all means just use “i” if at all possible.
Short variable names are acceptable as long as the scope is small.
The names i, j, and k are used traditionally in mathematics, so I use them when the context is suitable (not “xIndex”, “yIndex”, “zIndex”). However, I have found “fooBarIndex”, when the context is not mathematical, can improve readability.
Better still is to use iteration constructs that relieve you of managing the loop counter yourself, or map/fold functions.
Could be summed up by
‘don’t be a dick’
Dunno if making a 1000 line program into a 5000 line program is ‘better’
I would not think the measure would be if a newbie can read your code, but if the device can read your code, and how many clock counts it takes it to do so
how many commented out piles of crap are there
python indentation, has to be one of the best ideas in programming ever.
… until you get two programmers, one of whom indents with tabs and the other with spaces.
Precisely. For a language that relies completely on indentation, Python sure is bad about flagging indents as a syntax problem. Instead, you get mysterious empty error messages that might refer to the line just before the cited code, or 30 lines above.
And god forbid you have a chunk of code in a try/except block that you then need to debug. You can’t just comment out “try” and “except”; you have to unindent the entire block of code, find the error, then re-indent it, and hope you don’t accidentally screw up the indentation in the process.
One workaround to that is to replace the
trywithdef _fn():and theexceptwith_fn(). That’s easier to undo.Python indentation is the single worst thing ever done in the history of computing. Get used to coding in Python and then try going to … well any other language in the world. Or try making the shift the other direction. Too bad, but there probably isn’t anything that can be done about it at this stage.
“Python indentation is the single worst thing ever done in the history of computing.”
Even worse than Hungarian Notation?
Ha! Well that certainly rates right up there. At least it isn’t baked in as part of the language, it is just a nasty coding convention that I can choose to ignore. And that I rarely encounter in my corner of the world.
Way back when Delphi 1.0 was the hottest thing on the market I struggled with an instructor who insisted we all use Hungarian notation for every bloody little thing . IIRC it was heavily pushed at the time by the code monkeys @ Microsoft. Horrible, just horrible.
Just use #{ and #} in your Python code.
Drives the Pythonistas nuts!
But, if your indentation ever gets messed up, a simple program can straighten it out.
Elitists are everywhere but the art is how to navigate the rough sea that’s full of trolls, or rather find some quieter bays that are here and there where some great people reside to take beginners to the next level. One such place is dpreview Canon xxxD forums (photography related, though more technical than artistic) where I moderate every now and then and answer beginners questions. The trick is the create your own space where there’s good natured talks about the things that interest us and utterly ignore trolls. They usually dig their own graves anyway. One great way to deal with elitists and trolls is to be very courteous and correct with them, so they can’t find fault and if they do, they make a complete idiot of themselves, which is often the case.
I’ve also taken up an account on stack overflow to answer some questions. The problem is though that most of the obvious questions have already been answered and can easily be found with a query or two in google. The harder questions are such high level that’s either hard to answer or the question is very unclear, which is the second problem on stack overflow. Then bickering ensues as to the meaning of the question, by which time we’ve lost the original poster (OP). Because many beginner questions are already answered, the whole system isn’t built for beginners anyway, or so it seems. It’s not a beginner friendly place. But there are plenty mailing lists, forums, newsgroups, chat channels etc to get great beginners help, though it may take a while before you find them.
I remember that learning programming was a great struggle for me, but also very rewarding. In the late ’80 few people were into programming so it’s something you learn all on your own and documentation was often incomplete. I still learn a new language or concept on my own, with some videos, short examples on the internet and lots of patience and time reading and to let it sink in.
The problem for beginners now is the sheer volume of what needs to be known before one can program something interesting or remotely useful, fun or meaningful. In the ’80ies many 8 bit home computers came with simple to use basic interpreters which taught the basics. Nowadays people start in the convoluted world of programming a website, or writing a macro script, for which deep knowledge of the surrounding system is necessary. There are of course exceptions, like minecraft, that has the basic building blocks for logic programming even a 10 year old can grasp. Learning as you play and play as you learn can be a lot of fun and rewarding.
Something like SHENZHEN I/O.
And writing obtuse code isn’t limited to C (or Forth).
Here’s an old (’70’s) gem in APL:
(2=+⌿0=(⍳X)∘.|⍳X)/⍳X
There is a famous one-line APL program that implements the Game of Life. I can’t remember it, but after intense study I did once manage to grasp it.
Too bad HAd comments are free… They would have made a lot of money on random commenters
Many people would really hate how I code in BASH scripts, assigning values to variables by invoking a sub-shell that runs multistage command pipelines written as a one-liner, but I just cannot bring myself to care because it works and that is how my mind sees things. The side effect of the Linux kernel spreading the pipes over all of the available CPU cores rarely gets noticed until somebody tries to write faster code, and then I get to make that smug face.
Until you get run over by a bus or otherwise terminated and someone else has to figure out how to do it.
Yes, never ever try to replace me with a person with a lower IQ. If you want to employ a skilled coder ask them to explain how my code works and why it is so compact and fast. If they can then feel free employ them and to run a bus over me.
Did you know a recent study in India, by an Indian company found that 98% of programmers there were inadequate?
Make it easy for them and it takes even longer to discover that they are faking it. We code for machines, not humans, let the machines be the judge of our work.
As a developer of 20yrs + experience I look on in bemusement at the developers I work with who are <5 yrs experience all preaching and practicing the latest trends in bureaucratic development patterns.
The end product speaks volumes though.
Test driven development where the tests really only test the adherence to the latest trends and not the business logic.
A product where development takes twice as many developers and twice as long to achieve very little.
A product that needs to be rewritten because the business logic is incorporated into the application structure and fixing any minor bug means rewriting half the application.
Compare to old school functional development where business logic can be swapped out or refactored with ease and isn't smeared throughout a codebase where most of the code exists purely to comply with the bureaucracy.
Worse though is that I've seen companies go under trying to support the weight of it's development standards.
The reason we’re more tolerant to hardware slop than software slop is that hardware costs money, and sometimes that means you have to hack things in order to use what you’ve got, rather than use the “right” part that costs a lot of money.
In contrast, with software, doing it right costs no more than doing it poorly.
I think half the problem is that we try to evaluate and agree on too much about coding.
do_you_hate_capitals or doYouHateSpaces?
Coding is a compromise between how humans think and how computers function. How computers function is very well specified and is not at all ambiguous.
On the other hand how a human thinks is different from one tho the next. If you believe that *your way* of doing things is correct / supreme then you are simply aligning yourself against someone else that thinks *their way* is *more* correct!
Humans are subjective in nature so there is no ultimate *correct* methods so almost everything else is just opinion.
There is much we *can* actually agree on so we should be satisfied with that and accept that there will always be much we don’t quite agree with.
CamelCaseDoesNotBotherMe.
I-hate-underscores-because-they-are-harder-to-type (Lisp and Forth allow hyphens in identifiers).
Maybe when working on a codebase with underscore_separated_identifiers I should remap the key so that it types underscore without shift.
Time for some prolog?
http://kti.ms.mff.cuni.cz/~bartak/prolog/sorting.html
At work, I design and code to a really strict safety standard which prescribes everything you do. At home, for my own projects, it just has 1) work and, 2) be clear enough that I can debug it or re-use it 6 months down the line. Sometimes that means I follow the same things I’m used to at work, but often a lot of the overhead of that environment is dropped.
As expected, this topic has brought a lot of comments so I will throw in my 2C worth. First, many people get confused about the difference between architecture and design and coding. Learning how to code is not learning how to build software systems. A lot of education seems to be oriented towards coding only. I usually use the word programming to cover both design and coding with software architecture being separate. This is just a convenient distinction for me. Much more emphasis should be placed on architecture and design than coding unless you have very restricted hardware. Once you have a good design, the coding language doesn’t matter much although, when you have a choice, some languages are more suited to certain problems than others. I generally use “Occams Razor” and pick the simplest language that will do the job and with which I am familiar.
The next issue is how to balance between designing software based on the “real world” problem and designing based on the target platform. As the cost of computing power drops, the designs can be closer to the structure of the problem than the hardware. This is good as it usually makes the system more flexible and easier to maintain. Some programmers are too interested in creating the most “elegant” or efficient code. It may then run very fast and the source code may be very compact but the cost, in terms of debugging, maintenance and reusability will usually be very high. Readability is very important. I can forget why a few lines of code are the way they are a few days later when I am working on something else. Add comments everywhere! It is usually a pain when you want to get code out of the door but the discipline is worth it.
Finally a word on refactoring. Often when I start programming, especially on hobby projects which usually only have a few hundred lines of code, I start with code that does the job but is not well structured. Over time, as I debug, I rewrite sections of the code as I find better structures that are closer to the problem structure, easier to understand and more flexible. Even when the code seems to be working perfectly, I will often go over the code looking for ways to make the structure better (by the above measures) before finally committing the code. It is important for beginners to understand that debugging by “tweaking” the code again and again can lead to messy, unreliable software so they need to stand back every now and then to see how they can simplify the structure of the code (and overall system) and sometimes rewrite code that seems to be working perfectly.
Awesome! Comprehensive. Short!
(jealous!)
Arrogant behavior betrays ignorance and insecurity. Most programmers are full up with it. The very idea that good enough is OK ( which every other human en devour accepts ) is foreign to them. In their mind anyone who violates one of their pet peve rules is contributing nothing. It’s a club for narcissistic juvenile weak minded assholes. I prefer math and physics where there ARE right and wrong answers. Programmers get over yourselves.
There’s probably a lot of web sites where you will get a less harsh response to that statement than this site lol.
Code is not a lot different to other commercialized services. You get what you pay for.
So when it comes to the poor code your complaining about, it’s actually you that chose that poor code when you decided what you are willing to pay.
I can write secure code but I want more for that secure code than some person in India wants for non-secure, poorly stitched together open-source libraries.
Consumers don’t see the benefit of paying the extra money for what to them is the *same* code. Well at least until they get hacked but by then they are committed.
There are poor very poor coders and then there are very good coders.
If you believe that all coders are poor coders then that simply clarifies which coders you are choosing.
Well no comment from the peanut gallery
“When someone builds a bridge, he uses engineers who have been certified as knowing what they are doing. Yet when someone builds you a software program, he has no similar certification, even though your safety may be just as dependent upon that software working as it is upon the bridge supporting your weight.”–David L. Parnas
“There are no standards for computer programmers and no group to certify them.”–David L. Parnas
Scientists and engineers stand on each other’s shoulders. Programmers step on each other’s toes.
You lost me as soon as you dumped on the ternary operator. When used appropriately, it is a wonderfully elegant piece of code. Like all constructs, it can be abused. Cleanly written and commented, it is very useful precisely because it is so compact. The following code is EASY to understand:
my_var = (input > x) ? bigger : smaller; // assign bigger to my_var if input > x, assign smaller otherwise
We could write it as an if/else statement, but that seems overkill for such a concise operation. On the other hand, this:
(input > x) ? function1() : function2(); // call function1() if input > x, else call funciton2()
Being more procedural rather than about assignment probably would be better served by an if/else block. Every tool has its place and every place has its tool. Dogmatically discarding tools generally is a bad idea.
A single line statement can equally be used with ‘if’ so your comments relate just as much to how white space is used –
If (condition === TRUE) {success = "Yes";} else {success = "No";}Also with a ternary you loose a set of round brackets that otherwise make it clear that the operation is Boolean comparative. Many languages have the ‘==’ comparator to distinguish it from the assignment symbol ‘=’ however *some* languages do NOT make this distinguishment so this shorthand ternary can very easily be visually ambiguous.
Also with this –
output = foo > bar ? fizz : buzz;Not only do you loose two round brackets you also loose two lots of curly brackets.
The symbolic meaning of round brackets is the same in all languages because it comes from basic math where the section within the round brackets must be independently evaluated.
Much the same can be said of curly brackets and their cross-language meaning however there is one other aspect that is true of curly brackets and that is that any coder of any language that uses them has had his eyes very well trained to matching pairs of curly brackets.
Also this below is acceptable in most languages –
If (condition === TRUE) {success = "Yes"} else {success = "No"}But it is a very poor coding style. Removing deliminators like ‘;’ increases the risk of flow errors.
How many people have spent a lot of time looking for this ? –
If (condition === TRUE);{
success = "Yes";
}
It’s precisely the extra brackets, etc. that I feel are unnecessary. Add enough brackets to any equation or predicate and after a certain point, it gets less and less readable. If the whole point of an if-statement is to choose which of two things to assign to an Lvalue, then the ternary operator is wonderfully concise.
My point was more that we should not be dogmatically outlawing this or that construct. Each has its place and use.
I always try to follow the when-in-Rome coding philosophy. When I need to contribute to someone else’s code (or code that I have inherited from someone else), I read around where I am contributing and do my best to adopt whatever coding/style conventions already are in place. I’ve had to maintain enough pre-existing code where everyone who had touched it before me insisted on using their own variable-naming and curly-brace conventions to know that that is a practice best killed with fire…
When you sit down to make a contribution and find code that looks like this:
if(cond_1 == cond2){
myVar = input_condition; }
else
{
doSomething_else();
}
You want to find the committee that wrote it and throw them off of a cliff!
I just wish I had a mentor. I have helped many people over the years with the limited knowledge that I have and got them into electronics, but have yet to meet someone to give me a hand and teach me. I am not really into hackerspaces and the like (just wasn’t a good fit) but would like a nice, knowledgeable person to tinker with. Anyone have any ideas of how to go about achieving this?
Well here I am lol!!!
If your happy with internet and email, I am an old person (read “very experienced”) that has lots of time.
That code types and hardware types are you interested in???
My io page is here – https://hackaday.io/projects/hacker/12113
I have a home workshop and would be very interested to share it with other people but there doesn’t seem to be any Geo-oriented platforms to make these connections. I am in Far North Queensland in Austraaaaaaaalai.
Wow! Just think of all the lag time in getting “1”s and “0”s all the way out there and back.
0.1 0.1 0.2 0.2 0.2 0.3 1.2 4.7 4.6 4.6 3.1 0.8 0.3 0.1
Thank you very much for the offer :) You are a good bit advanced compared to my doings, so if you don’t mind “coloring with crayon”-level electronics then I am game. I live in the US but don’t mind doing WoT emails back and forth :) Will give you a shout. Thanks again and hope you have a great weekend :)
“What does a neophyte programmer do when they get stuck? The same thing the pros do. Hop onto Google” XD
I wish I had a online mentor when I was learning, would’ve made things much quicker, maybe that’s why I like to help others.
“Learning coding from a mentor is a rewarding experience both for the student and the mentor themselves.” – Is so true, not only do you get to help someone else make progress, you get a chance to go over and double check basic’s which you never would’ve done if it wasn’t for it. Like the other week I found out you could have prefix operators, always having always used suffix e.g “i++” I never even considered prefix being an option! But now I know.
Did they make a A.I that can code in all languages for us yet?
I learned Pascal in 1985 from a book, and it was an amazing experience. At the time finding information was very challenging, and the little information you did find was so important that you really valued it and focused on it.
Today there is so much available, including libraries to solve most hard problems and snippets of code to get you going without putting in the hard work. It is not better or worse, it is different. You can learn faster if you put deliberate intent into absorbing the information and understanding it. However, it can be detrimental if you listen to the wrong sources or just copy and paste code blindly.
Mentors are great, but choose wisely and stay away from dogmas.
Minor note: When posting XKCD links, could you please us explainxkcd.com? Same thing, only expanded and notated. http://www.explainxkcd.com/wiki/index.php/1185
YESSS. Great article. I really like the mention about how more seasoned programmers forget what it was like to be learning how to code in the first place. That’s why I started my blog. I started it when I knew nothing, I feel like being able to bridge that gap is really important and sometimes you need to talk to someone who is only a little more advanced than you in order to get a more relatable mentorship out of it. Nice Post!!