Messing about with coding

[Dave M]

There are roles for butterflies - mostly in organisations with multiple competing requirements and lots of in house systems. It becomes a requirement.

Easily distracted and not motivated though? No. What role above shelf stacking is that acceptable in? To be a butterfly you need to be superbly motivated although distraction by other projects is always a danger.

 

[Xyclops]

Sometimes being easily distracted implies you aren't really that interested in what you are doing rather than being a trait that's always present. Maybe the OP just hasn't found something that he's passionate about.

On the other hand the OP sounds lacking in confidence. That may be the problem. You have to believe you can do something to be really motivated to try. I would suggest a good starting point is to sign up to a programming course on udemy and follow it through to completion. Also LinkedIn has a learning platform and the courses done there will appear on your linked in profile for potential employers to see.

For what its worth, I am a software developer myself. Mostly C#, ASP.NET MVC and Vue.js.

 

[69Dude]

If you're already in corporate IT then speak to some people in your DevOPS area, ask them about entry level opportunities and to perhaps consider you if any secondments come up.

Coding proficiency is important but language expertise is not mandatory, unless it's in a lower level language that requires memory management and specific pointer use.
If you can use an object oriented language and do all the usual stuff like creating functions, classes, objects, methods and are comfortable with variables, constants, arrays and types of data and their compatability then you're good enough to apply.

My move to DevOPS was similar to your, being a service manager with little in the way of certs (for development) but I'd shown myself to be 'good' to some people in the area.

It's very important though that you can demonstrate an understanding of the concepts of programming with others.

Learn about and be able to explain in an interview:

• Multi tier environments (dev/test/production), what each is used for and why they are important
• Agile types of working, extreme programming/scrum and the advantages to devs and end users over waterfall projects.
  
• Version control for projects, (like Git) package pushing and reversion etc
• Change and release management processes
• Unit testing, logic check conditions and breakpoints into code modules for error detection and handling.
• Regression testing (does x new code feature impact older features)
• Defects (bug in coding or logic where service becomes unsuitable for use or expectations of user)

For bonus points be able to discuss

Why dates and times are issues for coding, things like UTC/Epoch dates
This is a time count since x date in 1970, account for leap years in milliseconds etc requires further code to identify daylight savings periods and regions.

Databases, general info on data structures.
Object data storage (json/nosql) vs flatfile (csv/txt) vs normalised databases (oracle/sql), casting data to other types. Data connections via odbc, oledb etc.

Regular expressions (you have this covered, what a nightmare)

Schedulers
Outside of the code platform, CRON jobs on unix, scheduled tasks on windows servers, sql server management studio scheduled tasks for DB's.

API's
Connecting to api's via the code platform, how to structure requests to the endpoints.

These are things that if you bring up in an interview lets them know you've been around.


It is correct though that you'll be googling forever because various corporate restrictions, environment configurations or language issues mean you have to work around stuff a lot.
Good code often isn't good when you're trying to integrate obscure and outdated services into each other.

 

[FoxEye]

So what are you guys actually doing (if I can ask that and it's not top secret).

I was thinking to myself today, if somebody said to me, "Think of an idea for an app," that just about everything has already been done. By 50 different vendors, most likely, all on at least version 12 of whatever app you care to name From accounting to flying a jumbo jet, by way of warehouse automation to word processing.

So I asked myself, what are all these coders doing right now? Either they've got some really niche specialism or a lot of people are re-inventing the wheel in their daily jobs.

Of course I don't have a clue, so this is a question of the non-rhetorical variety

But, unlike say a plumber where you have to have plumbers all over the country, how many spreadsheet apps does the world really need? Most of us just use Excel. Similarly, how many accountancy apps does the world need, when you've got Xero and Quicken and yadda, yadda.

So I'm back to imagining most of you work on really niche custom solutions for very specific needs, where off-the-shelf apps aren't available.

 

[Xyclops]

I work for a company that does niche software yes. Currently its an on premise solution but the development team is working on transitioning it to a cloud product. That's the way things are going. Most software will be run in the cloud eventually, so I expect many other companies that sell their software, rather than writing internal tools, are doing the same (or will be soon).

As for inventing a new app, you are right that at this point its difficult to think of a app that solves a problem or need that hasn't already been done. But there are almost infinite ways that an app can provide the solution. The problem is that your app would have to really stand out vs the existing players if you are to have a hope of succeeding.

For a lot of software I think it got "good enough" 20 years ago. I'd certainly have no problems using Microsoft Office 2000 for personal use (obviously that product not considered safe any more though due to vulnerabilities etc that Microsoft no longer patch).

 

[mid_gen]

So what are you guys actually doing (if I can ask that and it's not top secret).

I was thinking to myself today, if somebody said to me, "Think of an idea for an app," that just about everything has already been done. By 50 different vendors, most likely, all on at least version 12 of whatever app you care to name From accounting to flying a jumbo jet, by way of warehouse automation to word processing.

So I asked myself, what are all these coders doing right now? Either they've got some really niche specialism or a lot of people are re-inventing the wheel in their daily jobs.

Of course I don't have a clue, so this is a question of the non-rhetorical variety

But, unlike say a plumber where you have to have plumbers all over the country, how many spreadsheet apps does the world really need? Most of us just use Excel. Similarly, how many accountancy apps does the world need, when you've got Xero and Quicken and yadda, yadda.

So I'm back to imagining most of you work on really niche custom solutions for very specific needs, where off-the-shelf apps aren't available.

In a past life I worked in big banks on reporting systems. Back then it was typically Flash/HTML front-end, Java service tier, Oracle data store. Also worked on ledger systems that run investment banks, hardcore Oracle work.

For the last 6-7 years I've been in game development. Very few solved problems there, always on your toes having to come up with interesting solutions. Subject matter is naturally much more exciting than typical enterprise IT.

 

[randomshenans]

I want to build an outlook plugin that does some decent scheduling assistance. The OE one is useless and I'm fed up of scrolling through invitee availability to chuck something in. Should be able to click a button and it finds me a time suitable. That's what I want to build next.

 

[FoxEye]

For the last 6-7 years I've been in game development. Very few solved problems there, always on your toes having to come up with interesting solutions. Subject matter is naturally much more exciting than typical enterprise IT.

As a kid I always imagined that's what I'd do, funnily enough.

What kind of game dev do youdo? Engine development as far as I can make out is basically pure maths. And the kind of maths I was worst at to boot Trig and mechanics. My brain hurts when I try to think about that stuff.

AI? Typically a fairly weak point in most games. Inc pathfinding, etc.

I guess the great thing about game development is that each game is a unique problem and no two games are alike. It's not like accounting software where each product is trying to solve the exact same problems (based on the various real-world laws of tax returns and the like). To be a bit poncey, it's "coding as art", rather than utility.

The only thing (again AFAIK) that sucks about game dev is the environment. High pressure, lots of crunch, lots of projects that get canned. Unless you are an indie developer, but then where do you get your money...

I want to build an outlook plugin that does some decent scheduling assistance. The OE one is useless and I'm fed up of scrolling through invitee availability to chuck something in. Should be able to click a button and it finds me a time suitable. That's what I want to build next.

Surely there must be 100 existing solutions for this? It's a fairly obvious problem and this is what I meant about re-inventing the wheel. Surely somebody has done this already.

 

[mid_gen]

As a kid I always imagined that's what I'd do, funnily enough.

What kind of game dev do youdo? Engine development as far as I can make out is basically pure maths. And the kind of maths I was worst at to boot Trig and mechanics. My brain hurts when I try to think about that stuff.

I'm an AI programmer, but do general gameplay stuff, and some tools. Engine programming is more about building tools and frameworks to build the game on. Not necessarily math heavy. Graphics programming is the really maths heavy stuff. You don't need to be a maths expert though, as long as you can look things up in a reference and implement them in code.

AI? Typically a fairly weak point in most games. Inc pathfinding, etc.

Sometimes I wish more people worked in AI development and understood what goes on. Making AI in games isn't about making 'smart' AI agents, it's about making a fun game. It's easy to plumb in a neural network that learns and does all sorts of interesting things, but it's completely useless to designers, impossible to balance, zero fun. Pathfinding and the like is a somewhat 'solved' problem, but it's still very expensive.

I guess the great thing about game development is that each game is a unique problem and no two games are alike. It's not like accounting software where each product is trying to solve the exact same problems (based on the various real-world laws of tax returns and the like). To be a bit poncey, it's "coding as art", rather than utility.

Writing code for games is very rarely about finding 'the' solution to a problem. It's finding the cheapest, most abstract way of implementing a game feature. Having only 16ms to update everything in a game world presents very different challenges to financial software, where the primary concern is that the numbers are correct

The only thing (again AFAIK) that sucks about game dev is the environment. High pressure, lots of crunch, lots of projects that get canned. Unless you are an indie developer, but then where do you get your money...

That's not the case any more, certainly not in my experience. The work environment is a world away from the awful toxic workplaces you get in investment banking. Everyone knows which studios expect people to crunch their health away, and it's easy enough to avoid them. Projects getting canned? Not necessarily a bad thing, sometimes what started out promising turns out to just not be very good when you make it. The money in engineering at the big studios is pretty decent. Plus you get to work with a bunch of interesting people, musicians, writers, artists, instead of just a grey office full of techies

 

[FoxEye]

Sometimes I wish more people worked in AI development and understood what goes on. Making AI in games isn't about making 'smart' AI agents, it's about making a fun game. It's easy to plumb in a neural network that learns and does all sorts of interesting things, but it's completely useless to designers, impossible to balance, zero fun. Pathfinding and the like is a somewhat 'solved' problem, but it's still very expensive.

Writing code for games is very rarely about finding 'the' solution to a problem. It's finding the cheapest, most abstract way of implementing a game feature. Having only 16ms to update everything in a game world presents very different challenges to financial software, where the primary concern is that the numbers are correct

So if you don't mind me asking, how did you get into AI programming? I can imagine it's probably one of the most interesting programming fields there is.

Any good resources - quite basic ones - like "baby's introductory guide to AI?" Good ones, that you'd personally recommend.

Re the pathfinding. I don't know if you've ever played Dwarf Fortress (most game devs are probably aware of that one, the one-man-band creator does a lot of events/talks). Pathfinding as I recall is the primary reason most DF games end in "FPS death". The game starts at 100FPS, and by the time you get to a large-ish fort with 1000s of units/mobs, all of which are pathfinding all over the map, the game eventually craps out at 5FPS then dies I'm sure they've got their own tricks to minimise the area being searched each tick, but yeah, pathfinding in that game is actually something the player has to be acutely aware of, in order to try to help the game out and keep FPS up.

I played around with a really basic pathfinding algorithm years ago making a crappy isometric thingy which I abandoned after a few weeks as per usual Got me thinking back then about how you take something really brute force and start to make it more efficient. You quickly realise it ain't simple Esp if your map isn't static (as per DF) and you can't define nodes to get from A to B optimally (forgot what the term for that is).

But yeah I can tell you enjoy your job

 

[mid_gen]

So if you don't mind me asking, how did you get into AI programming? I can imagine it's probably one of the most interesting programming fields there is.

Any good resources - quite basic ones - like "baby's introductory guide to AI?" Good ones, that you'd personally recommend.

AI means different things to different people, especially the last few years. Game AI isn't really a single discipline subjects. Broadly it's a subset of gameplay programming that includes : Navigation and pathfinding, decision making systems (behaviour trees, planners, utility systems etc), perception systems. Anything that relates to non-player entities in games having any agency basically.

I got my foot in the door in games about 7 years ago now doing some front-end work and decided AI is where I wanted to go, so I write some plugins for Unreal in my free time, a goal oriented action planner, and a 3d navigation system, and gave some talks in the studio on that got me noticed by the tech director on a project that needed an AI programmer....and from then on I've been an AI programmer

Re the pathfinding. I don't know if you've ever played Dwarf Fortress (most game devs are probably aware of that one, the one-man-band creator does a lot of events/talks). Pathfinding as I recall is the primary reason most DF games end in "FPS death". The game starts at 100FPS, and by the time you get to a large-ish fort with 1000s of units/mobs, all of which are pathfinding all over the map, the game eventually craps out at 5FPS then dies I'm sure they've got their own tricks to minimise the area being searched each tick, but yeah, pathfinding in that game is actually something the player has to be acutely aware of, in order to try to help the game out and keep FPS up.

Pathfinding is most of the time done using a graph, and traversing it with an A* algorithm. A graph is just a system of Nodes, that are connected by Edges. The algorithm goes to a node, inspects all the edges that run from it, and makes a list of new nodes to explore from that, rinse, repeat (highly paraphrased). The problem with it is that when your graph gets very complex (i.e. you have a massive Dwarf Fortress), the number of iterations in that algorithm has to run to get from it's start node to it's end node explodes. You just don't have enough cycles in your frametime to do it, and your framerate plummets. There are various techniques you can use to try and reduce the number of iterations, but you can't avoid the problem entirely.

I played around with a really basic pathfinding algorithm years ago making a crappy isometric thingy which I abandoned after a few weeks as per usual Got me thinking back then about how you take something really brute force and start to make it more efficient. You quickly realise it ain't simple Esp if your map isn't static (as per DF) and you can't define nodes to get from A to B optimally (forgot what the term for that is).

But yeah I can tell you enjoy your job

I doubt the algorithm has changed, A* is mega simple.

 

[Mason-]

I create testbenches to simulate GPU hardware IP. To make sure it does what it should and to find bugs. So that our licensees don’t start the fab process and realise there are bugs when it’s too late and they’re out and about in your smart phones and tablets.

It’s quite a niche language: SystemVerilog, and the associated paradigms are quite niche too.

It’s also a grey area to some as to whether what I do is hardware or software development. I’d definitely say it’s software myself, but really it’s both. The code I write is executed on a processor to simulate and test semiconductor hardware. That’s software to me.

 

[R.P.L]

OP, your relationship with coding sounds a little bit like mine. I find it interesting and have done it on and off as a hobby for years, but I rarely complete anything worthwhile. Once I understand the basic concepts then I just move on mentally and lose interest. I have automated quite a few Excel things using VBA at work over the years, and I think having a very tangible end goal is important and something that it sounds like you're lacking (and usually I am too).

 

[69Dude]

So what are you guys actually doing (if I can ask that and it's not top secret).

I was thinking to myself today, if somebody said to me, "Think of an idea for an app," that just about everything has already been done. By 50 different vendors, most likely, all on at least version 12 of whatever app you care to name From accounting to flying a jumbo jet, by way of warehouse automation to word processing.

So I asked myself, what are all these coders doing right now? Either they've got some really niche specialism or a lot of people are re-inventing the wheel in their daily jobs.

Of course I don't have a clue, so this is a question of the non-rhetorical variety

But, unlike say a plumber where you have to have plumbers all over the country, how many spreadsheet apps does the world really need? Most of us just use Excel. Similarly, how many accountancy apps does the world need, when you've got Xero and Quicken and yadda, yadda.

So I'm back to imagining most of you work on really niche custom solutions for very specific needs, where off-the-shelf apps aren't available.

Corporate programming, specialising in data management.

Large insitutions will carry a large number of services and in house applications.
Imagine your company wishes to change from one popular HR platform to another off the shelf solution, someone needs to build out the api connections, authentications, any custom web development and test everything to ensure it's working correctly.

In another case, you might have a semi custom application built on a popular platform, like oracle forms.
When the business wants a new functionality, it requires developers. Being a programmer isn't about inventing new apps or revolutionising the world, it's more about keeping things working and installing new platform upgrades to keep them modernised as everything develops.

Off the shelf services, even the most popular ones are all custom niche solutions because businesses are unique, even common ones.
To give an example, excel is used everywhere but custom macro modules in visual basic are all unique. You might need a module to do the same thing that 1,000 other businesses have written one for already but your corporate context is unique, naming conventions, share drive locations, specific data formats in the output so a document is in the right flatfile column order and data formats are correct to upload into another system etc.

A mechanic could invent a new car or manufacture a car but most just fix broken cars and upgrade them so they remain compliant to the current MOT standards.

Your viewpoint is that of, you are a vehicle specialist, therefore your job is to invent new cars all day or to invent new components.

 

[dowie]

I was thinking to myself today, if somebody said to me, "Think of an idea for an app," that just about everything has already been done. [...]

So I asked myself, what are all these coders doing right now? Either they've got some really niche specialism or a lot of people are re-inventing the wheel in their daily jobs.
[...]
But, unlike say a plumber where you have to have plumbers all over the country, how many spreadsheet apps does the world really need? Most of us just use Excel. Similarly, how many accountancy apps does the world need, when you've got Xero and Quicken and yadda, yadda.

So I'm back to imagining most of you work on really niche custom solutions for very specific needs, where off-the-shelf apps aren't available.

Meant to reply to this previously but to add to the above reply... firstly there are new apps created/new ideas implemented every day.

Look back say 10 years ago - How many people were writing control systems for vertical farming 10 years ago vs today? How many people were implementing chatbots to use on on their customer service web pages (and if you've used one can you see how bad some are and how much room for improvement there is)? How many companies were using NLP to read legal documents? Were robots in e-commerce warehouses as efficient as they are today?

Even if you put aside the "new" stuff - consider that it can often take more people to maintain software than it did to build it in the first place. I'd wager that the team at Microsoft currently maintaining and upgrading their Excel application is significantly bigger than the team that originally created the first version! It's not like there isn't room for new development within existing projects too... that's what new versions are for (it's not all just creating something and leaving it at that aside from fixing bugs) - the original version of Excel (and various versions subsequent to it) wasn't deployed via the cloud for example....

Lastly even putting aside new development/incremental improvements to existing products there are all those bug fixes etc.. with whatever is deployed. In the case of mass market retail software it's generally a small subset of versions (for say windows, linux, mac OS or android/iphone) and the aim being to maintain say the current version for those platform and maybe the one before and the one before that(in the case of mobile apps it's more like you must just upgrade, all fixes in the new version).

Could be a completely different story in enterprise software... the client might need it to work with their existing systems and when the vendor filled out the RFP there were gaps, whichever vendor the client chooses might require some development - this development might take the form of customisations by the vendor to their software... or it might take the form of inhouse development at the client, working with the APIs on the new software and the existing software and perhaps the software being replaced (if applicable). Just upgrading one system that perhaps costs 10 million could involve a bunch of developers at the vendor working on customisations and/or a bunch of teams at the client working on stuff to make sure the new software plays nicely with other stuff... Not to mention plenty of other roles involved from project managers to business analysts, QA guys and of course people on the business side: end users and management at the client.