Live data from Hacker News

Tales of coding from a beginner

medium.com

51–60 of 87 posts

Re: Tales of coding from a beginner

#51
"3. Equals is a lie: = ≠ ="

This is why languages like Pascal (and it's descendents) use := as assignment.

There are contradictory opinions about sytnax among programmers. Many programmers don't like the example assignment syntax above, but then many programmers also say that syntax is a relatively minor aspect of learning a language (even though the syntax of a language shapes the way you think about solving problems).

And many programmers do avoid certain languages precisely because they dislike the sytnax.

Nikalus Wirth, who created Pascal, Modula-2 and Oberon, had this to say about using the equal sign for assignment:

"A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to Fortran in 1957[a] and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let “=” denote a comparison for equality, a predicate which is either true or false. But Fortran made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x."

Re: Tales of coding from a beginner

#52
post #49

Earlier quoted context omitted.

Probably, chef work is not that similar to programming. Construction would be more prolific analogy. Note using of construction related language in software world, eg "development", "architecture".

That's true when programming for a job or otherwise trying to get serious work done. But programming can (and also should) be play. For me it's explorative and playful, I'm just trying to make a fun thing happen or see what things I can connect together in what interesting ways. I imagine it's the same for kids taking their first steps by making lights flash with a RPi and Python and then wondering what they can do n…

I agree. While learning it is (or should be) playing with the code and having the most fun, somwhere along the career path you find yourself being an engineer first and everything else second.

Re: Tales of coding from a beginner

#53

Question: I'm curious to hear other people's experiences with "4. Stop asking questions". I ask questions quite a bit. It does slow me down. But I feel like if I understand something, I can move faster in the longer term, besides the value derived from just understanding how the system/abstraction works.

I think the point is to stop asking broad question like "Why doesn't this work?" before trying to figure it out yourself. In the process you will learn much more than just have the question answered in an equally broad form of "Oh there's a semicolon missing here". You still don't know why that semicolon was required in the first place afterwards.

Re: Tales of coding from a beginner

#54

Question: I'm curious to hear other people's experiences with "4. Stop asking questions". I ask questions quite a bit. It does slow me down. But I feel like if I understand something, I can move faster in the longer term, besides the value derived from just understanding how the system/abstraction works.

both works: asking questions or not asking questions.

it mainly depends on the person

some ppl will learn by doing, they just want to go out there, break stuff, break it, break it, break it again and then they understand it

other ppl will want to know the subject even before writing the first line of code, so they ask questions and questions till they feel they have the thing figured out and they can start

yet other ppl will make an honour point to never ever ask a single question, they would rather spend hours reading doc, specifications, RFC, and whatnot

Who is to say there is a best way? I don't think there is

as a dev what I don't like is beginners asking a bit too obvious questions when all the answers are in the documentation if they took few minutes to read it, and what I really don't like is ppl asking questions feeling entitled to an answer like you owe them

but again it's my personal view on the thing, it's different for everyone

for example, I'm mentoring a friend and he often comes "I will bother you again with a question" (he is learning JavaScript) and it does not bother me at all, whatever the question is: 1. already agreed to help him and 2. it's easy to answer

I would be more worried about someone who want to learn programming and who doesn't care if he/she understand stuff, or is not curious; eg. the "asking questions" part is more about being curious and/or motivated enough to understand things than the act of asking a question, there many ways to understand "asking questions" is just another tool among "reading documentation", "reading previous answers to other ppl questions", etc.

my point: the pace you learn things is totally personal, if you think asking question is faster and you are concerned about the speed then ask a question; but then I could argue in some case you can ask a question and never get an answer (stack overflow) and maybe it is faster to read the doc.

Re: Tales of coding from a beginner

#55
post #13

9. Learn to call it programming, not "coding". It's like a professional chef referring to what they do as "chopping".

That seems only to be a problem for native English speakers. Programming, coding, hacking, tinkering, etc... is all pretty much the same. Also, personally I think it has an elitism smell ('software engineering' is the worst). We shouldn't pretend that a 'professional software engineer' fresh from university can in any way produce better code than an 'amateur' who's at it for 20 years, because in my experience the experienced amateur is always a better programmer/coder/whatever...

Re: Tales of coding from a beginner

#56
post #13

9. Learn to call it programming, not "coding". It's like a professional chef referring to what they do as "chopping".

Also note that a chef does not come up with their recipes in the kitchen, and neither should a good programmer.

This sounds like a statement from the 90's when 'software architects' and UML were still a thing. Thankfully we are over this. "Designing software" away from the code only works in theory. You will only find out whether your design works during coding and testing, or even later when the software is already in the hands of the user. The only way to good software is through constant rewrite. Make a rough plan, but be prepared to throw it away with the first line of code. Making up the recipe while cooking sounds like a perfectly fine strategy to me.

Re: Tales of coding from a beginner

#57
post #13

9. Learn to call it programming, not "coding". It's like a professional chef referring to what they do as "chopping".

That seems only to be a problem for native English speakers. Programming, coding, hacking, tinkering, etc... is all pretty much the same. Also, personally I think it has an elitism smell ('software engineering' is the worst). We shouldn't pretend that a 'professional software engineer' fresh from university can in any way produce better code than an 'amateur' who's at it for 20 years, because in my experience the exp…

"Producing code" is to programming as chopping vegetables is to cooking. It dumbs it down and devalues it - deliberately so.

Re: Tales of coding from a beginner

#58
I absolutely agree about the words 'just' and 'obviously'. I've been trying to cut them out of my vocabulary. The word 'just' has this feeling of being short with someone. And that they are a fool for not knowing what to do already.

"Just put the book down over there". "You just need to..."

Re: Tales of coding from a beginner

#59
I went from basically zero (a week of C in college) to where I am now by working on it pretty much every day. And the only way that was possible was because I actually like programming. She should say something about how her motivation levels are doing.

In terms of development as a coder, I think there's a number of plateaus. It's easy to recognize those below you, hard to see those above. So here are those I came across:

- Able to make simple modifications to other people's code. Everyone starts here. If you see backgroundcolor = red, what happens if you make it blue? You have no idea of what the platform is, how the codes executes, what slightly unusual syntax means, etc. At some point, you will exhaust the places where your guesswork works, because there aren't that many straight replacements in most code.

- Able to implement your own functions. Some Excel spreadsheet doesn't have a function that you want. You type it out and testing is a few times will uncover some corner cases that you can fix. Still no idea of how to organise things, especially since the trading floor mentality is that time is money. So you have an ungodly amount of VBA functions, all over the place. There's an enormous number of guys in finance at this level. I went to see some guys from a well known bank running several billion dollars of funds with this kind of spaghetti.

- Realised that Excel is a crappy way to organize code. Discovered you can write your own standalone programs without knowing everything about how the screen is drawn (and I still don't know the nitty gritty of it). When you realise a great deal of code is already written for you, that's massive. Of course I take the screen pixels as an example, but it's true in just about everything that you write. For the most part, you are glueing things together that already exist. So now I could write VB6 programs and .NET as well. Realised there was a lot I didn't know that was already working out of the box. I wrote a poker probability calculator back during the poker boom to help me give money away more efficiently (guess what, it's not just the odds that matter).

- Spent ages learning about SQL and databases. Looks easy from a distance, rows go in, rows comes out. But why does it take so long? What's an index? etc.

- Started to realise there's a whole load of interesting ways to organize code. Object oriented of course sticks out, and you can't avoid it. It will take a while to write classes that are not just oddly collected functions. Maybe run into the GoF patterns. At this point, a large rewrite might occur as various Eureka moments happen. Also you may be doing a LOT of backtracking, because OO isn't all that obvious. Maybe look at functional, or at least figure out what first-class functions means.

- Started to look at performance. The vast bulk of code up to now needed zero performance optimization, despite being inefficient. At some point, you wonder why a calculation that can be explained in a few sentences can take a non-neglible amount of time. Queue big-O notation. Memory profilers, timers. Threading issues. Cache coherence. Network stack.

- Started to look outside of finance. Web, apps, etc. You realise there's a value to being polyglot. Also that if the foundations are there, switching between technologies is not hard. Looked again at architecture for scale.

Anyway, I could write a book about this journey. Or I could just continue coding.

Re: Tales of coding from a beginner

#60
post #57

Earlier quoted context omitted.

That seems only to be a problem for native English speakers. Programming, coding, hacking, tinkering, etc... is all pretty much the same. Also, personally I think it has an elitism smell ('software engineering' is the worst). We shouldn't pretend that a 'professional software engineer' fresh from university can in any way produce better code than an 'amateur' who's at it for 20 years, because in my experience the exp…

"Producing code" is to programming as chopping vegetables is to cooking. It dumbs it down and devalues it - deliberately so.

I don't agree (and I don't agree with the whole cooking analogy). Writing code that is readable, maintainable, simple yet high-performing is a very important if not the most important part of the whole craft. We don't need high-flying words like 'engineering', 'art' or 'architecture' for writing good code. A great high-level design is worthless if the actual code is an unreadable mess, and I have seen plenty examples of this in the real world.
Post reply on HN