Messing about with coding

[FoxEye]

So my situation is really like a person who has learned to lay railway track, but doesn't know to where he wants to build a railroad.

So he lays a few meters of track outside his house, then gets distracted and goes to tend to his garden. And forgets about the railroad.

Over the years I've ducked about with coding in various languages, most of which are long forgotten.

Currently I deck about with Powershell for work (badly).

Before that, outside work I docked about with Javascript and sometimes the Google maps API.
Or a bit of Python.
Or C/C++.
Or Pascal.
All to the lowest possible standard, so that your 5 year old would be embarrassed to have produced it.

Or a couple times breaking out IDA and reverse assembling an ancient 16-bit DOS game, patching some stupid AI cheat into it with assembly and hex code. Because I love that game and the AI was useless.

I don't know anything about software patterns and I've never written a large program. Or a commercial program of any size. Mostly a couple hundred lines of crap here, a thousand lines of crap there. Before ditching it all and going back to the gardening.

This clearly demonstrates that I'm not a man of great creative talent nor do I have good ideas for projects of my own to work on.

And the code I write is probably useless and inefficient and crap and full of rookie mistakes.

But I can use Regex and Xpath and have seen other useless stuff like LISP and all sorts of nonsense like knowing the difference between STDCALL and CDECL and other random stuff that will never be in any pub quiz, ever. None of which will impress anyone.

I'm also ancient and on a post-40 downward trajectory!

Clearly, nobody is going to hire me as a coder. I sure as hell wouldn't.

Does any of this docking about count for anything or nothing at all? I guess that's what I'm asking. How easy would it be to turn the ducking about into some useful bullet points on a CV.

I still don't have an idea for a killer app so there's no point in just starting something that I won't bother to finish through lack of interest. I mean to a certain extent everything's been done. There's already a billion billion apps for everything on the App Store, whether it's herding virtual goats or an app to design the nipples on your custom-made 3d printed double dong. There's like, nothing left to do that Simpsons hasn't already done.

So yeah. What are your thoughts.

Oh, btw, right now I'm an admin bod. IT admin but it's still just configuring a bit of crap here and pushing a button there. I'm not even good at it.

 

[randomshenans]

Does any of this docking about count for anything or nothing at all? I guess that's what I'm asking. How easy would it be to turn the ducking about into some useful bullet points on a CV.

Unless you could class yourself as proficient in any of those languages, then not really. You should, if you want to take it to the next level, look on places like udemy/coursera and run through some courses of different levels. You'll build something in the courses, so you don't have to think of that idea yourself.

I still don't have an idea for a killer app so there's no point in just starting something that I won't bother to finish through lack of interest. I mean to a certain extent everything's been done. There's already a billion billion apps for everything on the App Store, whether it's herding virtual goats or an app to design the nipples on your custom-made 3d printed double dong. There's like, nothing left to do that Simpsons hasn't already done.

There are plenty of opportunities out there for new ideas. I wouldn't focus on that though, I'd more focus on getting a portfolio of things you've made from start to finish. Can be anything.

So yeah. What are your thoughts.

Depends where you see it taking you really; if you want to do it as a bit of fun, just keep ducking. If you would like to broaden your work horizons I'd look at what specific areas you'd like to work in and what languages and then focus on becoming better at those and get some courses behind you. Don't have to be expensive courses, but getting a number of these under your belt would be a good way to demonstrate your ability level.

 

[Randomface74]

Realistically nothing's going to come of it.

 

[randomshenans]

Realistically nothing's going to come of it.

Ask in 5years...

 

[dowie]

Unless you could class yourself as proficient in any of those languages, then not really. You should, if you want to take it to the next level, look on places like udemy/coursera and run through some courses of different levels. You'll build something in the courses, so you don't have to think of that idea yourself.

^^^ this.

re: this reply in the other thread:

The point is, starting from scratch, it's going to take you more than a few months to learn the simplest language constructs. You're hardly going to be creating a portfolio from the word "go".

Or do people start creating useful apps in the first weeks of picking up their first book on programming?

Heck in the first weeks I just about managed "Hello, world".

For example see udacity nano degrees - say 3-4 months for some of them based on 10 hours a week (and these providers tend to be conservative about the time required so could likely complete much faster if motivated or with more free time).

Most of these nano degrees are broken down into a few stages - so you'll be guided through building say 3 or 4 different things while covering the course. Then you'll have what they call a capstone project at the end, which seems to be something a bit more individual. So even just doing one of those you'd have perhaps 4 different things to put on a github from that alone. Only basic stuff but in that other thread that's all the OP was looking for from people, granted other jobs might want a bit more... so just build up a skill set and add to it.

I'd worry about this claim of only managing to write hello world across "weeks" - I don't know if you're exaggerating but how is that even possible, it makes no sense at all - you can literally open a book or online tutorial on say python or alternative and do that right away... going over the basic syntax of a language doesn't exactly take much longer either - you could get one of those learn python in 24 hours or similar books and go through it one Saturday for example....

I guess just grab a book/books or follow a course or series of videos online... build stuff and just learn something useful! If you can do that then there are people out there who might employ you if you've learned something useful. Pottering about and not really doing much probably isn't going to land you a programming job, though some familiarity with the basics might be helpful regardless.

I mean if you're in some IT damin role then why not build on that, do a bit of scripting, build up your skills there - look at progressing to a new role... isn't dev ops all the rage for IT admin types now? A little bit of programming isn't exactly a bad thing either for someone doing the IT admin/ops side of things.

 

[randomshenans]

isn't dev ops all the rage for IT admin types now

Would be my recommendation tbh. It's a mega important role and it follows a natural progression from your current work. Look at google's SRE stuff. It's booming.

 

[Blinkz]

I’ve been told by a few people that unless you find coding relatively simple/easy to pick up then you probably shouldn’t be looking at a job in it. Would you all agree? I’m doing a basic coding course and I’m enjoying it but I certainly don’t find it easy.

 

[iamtheoneneo]

I’ve been told by a few people that unless you find coding relatively simple/easy to pick up then you probably shouldn’t be looking at a job in it. Would you all agree? I’m doing a basic coding course and I’m enjoying it but I certainly don’t find it easy.

I think thats BS spouted by people that take themselves way too seriously. A lot of coding is problem solving and yes the Google meme applies to that.

You will never know enough about your craft, and just when you think you do another technology, or streamlined framework comes along that you have to adapt to. Or even within framework releases enough has changed for it to be a learning lesson.
Nobody I know in the job finds it easy but a large part of that is the actual work you have to do and a lot of it is just super dull.

 

[FoxEye]

The nuts and the bolts at the most basic level is close to trivial across all languages. That is to say, a for loop is a for loop is a for loop.

But it's the "more than one way to skin a cat" (I hate that phrase as a cat owner) notion that I get stuck on.

Sure I can build a solution, but it's not optimal. Should that be a class of it's own or just a couple of string properties? Should this be a property of that class in this module or should it live over here in this module. Should that be a global var or a pointer that I pass around.. Is this function doing too much and should I split it up into three simpler functions?

And that's where I get bogged down, making endless small changes that don't fix any real problem, but I don't code to any kind of deadline so I get mired in these kinds of niceties.

And I *suspect* that's where a formal training in software patterns and re-usable code would show me where I'm being a ****.

 

[FoxEye]

So this DevOps thing...

Definition[edit]
Academics and practitioners have not developed a unique definition for the term "DevOps".[a]https://en.wikipedia.org/wiki/DevOps#cite_note-6[c][d]

From an academic perspective, Len Bass, Ingo Weber, and Liming Zhu—three computer science researchers from the CSIRO and the Software Engineering Institute—suggested defining DevOps as "a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality".[6]

The term DevOps, however, has been used in multiple contexts.[7][unreliable source?]

I'll see what SRE is, but I'm curious what DevOps actually means... The above hasn't helped

 

[Burnsy2023]

So this DevOps thing...

I'll see what SRE is, but I'm curious what DevOps actually means... The above hasn't helped

Part of the training for what could loosely be called "trainee DevOps Engineers" (there are lots of things wrong with that statement, but I think it serves a purpose), is reading a few books. Have a read of the Phoenix Project and if you want more detail, the DevOps Handbook. It'll introduce concepts such as value chain mapping etc, which helps put all this in context.

 

[FoxEye]

Part of the training for what could loosely be called "trainee DevOps Engineers" (there are lots of things wrong with that statement, but I think it serves a purpose), is reading a few books. Have a read of the Phoenix Project and if you want more detail, the DevOps Handbook. It'll introduce concepts such as value chain mapping etc, which helps put all this in context.

Will do, ta. Sounds like a concrete first step to... somewhere

 

[Pho]

If you can show you're able to learn new languages and concepts quickly, and you have a passion for it, then I'd say that's enough.

We had a guy come to an interview who was a music teacher at a private school but picked up a passion for writing software during a module on his degree. He'd spent a lot of time playing around with loads of different tech. We hired him. He's been great.

 

[Mason-]

I think mastery of a specific language is overrated. Undoubtedly it'll make you more efficient and able to write code quicker. But in my eyes programming languages are a tool. If I were interviewing a person I'd be less interested in their proficiency in a specific programming language and more about their ability to solve problems.

Interviewing someone and expecting them to write perfect code that would compile first time in an interview to me is as silly as interviewing a writer and expecting them to write an article with 0 grammatical errors in it. The reality of the job is that you have code reviews, you compile, pre-commit checks etc etc. In the same way a writer gets their articles proof read. To me the brain is where the value is, the programming language is the tool to manifest the ideas within your brain. As long as you understand the fundamentals of how programs work then that's all you'll really need. As long as you've got the brain for problem solving the rest comes quickly, and @iamtheoneneo 's joke above is pretty relevant, I've been programming since 2011 in various languages. And I still google stuff that I knew how to do 8 years ago but have forgotten since because as far as I'm concerned they're not the hard part or even most important part of my job. My job is to understand complex things and come up with solutions, that's the hard part, not the coding.

In our first lesson of programming 101 at university our lecturer taught us: variables, loops, and if statements. And he said you now know how to write every program in the world. And he's right, conditions, memory and repetition are the core to any programming language. As long as you fundamentally know how they work and how to use them, different programming languages just put different wrappers/elaborations around those same things.

As for the OP, a lot of the big 'industry standard' patterns and tools and ways of working. You'll never really get to use them unless you work in the industry. Because for someone coding in their bedroom for fun you don't really need to use their methods. A lot of the things that are used in industry are necessary because many people work on a shared codebase, and because you won't always be the person who maintains/fixes the code you wrote a year ago. So a lot of the things you learn are to do with programming with those things in mind.

 

[fretted]

I think mastery of a specific language is overrated. Undoubtedly it'll make you more efficient and able to write code quicker. But in my eyes programming languages are a tool. If I were interviewing a person I'd be less interested in their proficiency in a specific programming language and more about their ability to solve problems.

Interviewing someone and expecting them to write perfect code that would compile first time in an interview to me is as silly as interviewing a writer and expecting them to write an article with 0 grammatical errors in it. The reality of the job is that you have code reviews, you compile, pre-commit checks etc etc. In the same way a writer gets their articles proof read. To me the brain is where the value is, the programming language is the tool to manifest the ideas within your brain. As long as you understand the fundamentals of how programs work then that's all you'll really need. As long as you've got the brain for problem solving the rest comes quickly, and @iamtheoneneo 's joke above is pretty relevant, I've been programming since 2011 in various languages. And I still google stuff that I knew how to do 8 years ago but have forgotten since because as far as I'm concerned they're not the hard part or even most important part of my job. My job is to understand complex things and come up with solutions, that's the hard part, not the coding.

In our first lesson of programming 101 at university our lecturer taught us: variables, loops, and if statements. And he said you now know how to write every program in the world. And he's right, conditions, memory and repetition are the core to any programming language. As long as you fundamentally know how they work and how to use them, different programming languages just put different wrappers/elaborations around those same things.

As for the OP, a lot of the big 'industry standard' patterns and tools and ways of working. You'll never really get to use them unless you work in the industry. Because for someone coding in their bedroom for fun you don't really need to use their methods. A lot of the things that are used in industry are necessary because many people work on a shared codebase, and because you won't always be the person who maintains/fixes the code you wrote a year ago. So a lot of the things you learn are to do with programming with those things in mind.

+1

 

[FoxEye]

As for the OP, a lot of the big 'industry standard' patterns and tools and ways of working. You'll never really get to use them unless you work in the industry. Because for someone coding in their bedroom for fun you don't really need to use their methods. A lot of the things that are used in industry are necessary because many people work on a shared codebase, and because you won't always be the person who maintains/fixes the code you wrote a year ago. So a lot of the things you learn are to do with programming with those things in mind.

Thanks for your reply. Want to zero in on this a bit.

What kinds of things (examples) are we talking about here?

I can imagine it's a completely different world to hobbyist coding.

 

[Lopéz]

Plenty of demand for Salesforce Developers if you can learn APEX (SF's own language, similar to Java) and Javascript and have a head for business logic and process...

Salesforce is quite an easy platform to immerse yourself in because there is an almost bottomless pile of excellent resources available completely free of charge. It's worth thinking about at least.

https://trailhead.salesforce.com/

 

[peterwalkley]

Thanks for your reply. Want to zero in on this a bit.

What kinds of things (examples) are we talking about here?

I can imagine it's a completely different world to hobbyist coding.

I'll give you two examples I've had to deal with this morning and its not even 9 yet:

1) FOSS. We need to make sure any third party library we are using comes with a non-restrictive licence, or the licence is known and a commercial agreement is in place allowing us to re-distribute that code alongside our own.
2) Coding standards. To ensure consistency across a large team a number of standards are in place that dictate very pedantic details like spacing of code, naming conventions for variables and constants, where curly brackets go, all child blocks get wrapped in curly brackets even if they're a single line and so on.

 

[Xyclops]

Not sure if intentional but you come across as someone easily distracted and not particularly motivated. To be a good developer you really need to have the discipline to just put your head down and work until the problem is solved. Obviously you may need to refer to websites/books/colleagues but the point is that an unfinished software project is a useless project unless the only goal of it was to learn.

 

[Xyclops]

BTW, didn't mean my previous comment in a negative manner. Its perfectly fine to be however you are. Just making sure you feel that you have the right mentality for the job