How do you find processes that can be automated? I've often thought that there must be a ton of this stuff in various industries where programmers aren't typically embedded.
Very common when you do tech work in a non-tech industry. Comes up a lot with coding-inclined mechanical engineers. Zed Shaw's words are really true:
> Programming as a profession is only moderately interesting. It can be a good job, but you could make about the same money and be happier running a fast food joint. You're much better off using code as your secret weapon in another profession. People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.
Man this is me. Knowing a bit of coding and machine learning in engineering has been such a boon over my career in civil/environmental engineering.
But it's like math, if you know it well enough, you'll find ways to use it everywhere. If you don't, you won't. You have to be the type of person that likes to innovate. Its hard to sell to prospective employers, but its great for demonstrating value once you are with an organization. All of my previous employers fight over trying to get me back when I've found myself looking for work. ...Now I work for myself and make my own work and I've priced myself out of their offers, but that's not so bad.
How much machine learning have you been able to pick up and did you learn formally (in school) or just on your own? It's a broad subject, so where would you recommend one begin, assuming I have a decent undergrad math background? Thanks!
Not the parent, but I did an undergrad maths/physics degree some time back and found https://www.coursera.org/learn/machine-learning to be good as an introduction, unfortunately a new job [unrelated] has prevented my finishing the course but I hope to pick it up again later in the Winter.
I would be interested in thoughts from anyone with ML experience who has reviewed said course's materials?
I've always had way too much math under my belt which helps a lot and have taught myself a lot of genuine computer science out of personal interest. I actually did Andrew Ng's Coursera machine learning class all the way through as a first introduction to that field before realizing it wasn't so mysterious and was just the application of a lot of math I already knew, then ran through a bunch of tensor flow tutorials when that first came out and the like. Then just experimented on my own. I have a knack for data though.
Formally from school, I've only had 3 semesters of scientific programming in Fortran and a shitload of math. That and years and years of building models and massaging data in Excel.
Mostly I'm just really used to learning a new API/tool and applying it to new things.
A lot of the ML stuff hasn't been fancy ML, just basic things but applied in really clever and novel ways.
Great quote -- surprised I've never seen it before!
In my limited experience, it's a mixed bag.
Good: you get special treatment/opportunities because of a unique skill set and increased visibility on the end results of what you do.
Bad: management doesn't really know what you do between software releases, you're paid the going rate for your industry while SWEs make far more, and in-house software quality standards might not be established/followed.
Side ish bonus: you're basically prepared to run a one man show or move into niche consulting (much much higher rates). You also get to set the quality standards/procedures going forward, which can be satisfying.
As a tangential bonus, I've accidentally converted my PhD research coworkers to strict git/markdown thanks mostly to typora (windows application). I showed one person what my work flow and version history look like for some internal documentation and now they do the same and convert to word/pdf as a last step. As far as I can tell, no one outside of the math/cs intersection has the patience for latex.
Source: in that boat.
Edit: In regards to market rates, that can be alleviated somewhat in follow up negotiations (6-12 months in or so). It's hard to convince someone what you're worth / what your value proposition is when they're not used to hiring software people. You need to demonstrate your business effect first, since they typically don't have a clear picture of it.
1. you _won't_ be happier running a fast food joint - the work is gruelling, and it's so easy to go bust. And you won't bring home six figures
2a. people who _actually_ can code are scarce, even in the tech industry. Source: conducted over 300 interviews
2b. quite logically, your coding skill will be most appreciated and compensated at a Big Tech Co, not at a government department where they will be simply unable to see the difference
>2a. people who _actually_ can code are scarce, even in the tech industry. Source: conducted over 300 interviews
As a young person with an interest in software programming (currently studying chemical engineering but still write C code now and then), what do you look for when trying to find out people who can _actually_ code?
I've heard this story before, but it sounds absolutely insane and I can't begin to imagine (let alone expect!) that such a thing occurs. Is it really true?
a somewhat serious answer: simple things should be easy to you, and hard things possible
examples of simple things: DFS/BFS walks; simple Project Euler problems; or "write a simple game in terminal, maybe with some form of minimax search" (a bit harder), or maybe a parser for simple arithmetic expressions
Same money running a fast food joint? You're underpaid bro or you know some crazy overpaid fast food managers. People from science based fields are coming to computer science because those other fields lack job opportunities at competitive pay.
I believe OP means running a fast food joint as the owner, not a manager employee.
Granted I don't know anything about that business, a quick google search comes up with an article from 2015 saying running a McDonald's provides an average annual profit of $150k so it sounds about in the right ballpark range: https://www.mymoneyblog.com/mcdonalds-franchise-cost-vs-prof...
According to this random quora link: https://www.quora.com/How-much-does-McDonalds-make-in-a-day the average McDonald's unit in the USA has $2,670,320 in annual sales. 25% - 40% profit margin sounds really high for a restaurant, but I don't know enough about the industry to dispute it. Are you sure those numbers were presented as averages and not the high end of what you could make? Or does the typical owner have multiple locations?
Very possible I skimmed and may have read it incorrectly, accounting is not my thing. As I have now reached the maximum amount of effort I'm willing to put into a forum comment, I'm not going to dig any further. But if you can tease out better information, I'd be curious to know.
From the document... Across ~12,000 locations they put the majority of restaurants in a range but they do have the numbers pretty well crunched.
Average profit margin 26-28%
Average gross sales 2.2 - 2.6M
Average operating income before rent/tax: 570k - 716k
"The rent paid to McDonald’s will vary based upon sales and McDonald’s investment in land, site improvements, and building costs."
It looks like that rent paid to McD's home planet is somewhere in the neighborhood of 10% of that investment (yearly? I guess?) but it seems to average about 100k-150k.
I suppose it's hard to match the salaries at The Big Corps working in other industries. Still, outside of software companies, people think I'm basically a wizard for doing simple things, like automatically generating climographs from JSON files. I just don't get that kind of positive reinforcement from software people. I think it's just more enjoyable to be the hacker rather than a hacker.
Any midsize company has tremendous amount of things that could be automated. For example, I work at manufacturing company, we produce parts for bigger companies. Bigger companies already have APIs, web portal, etc. We have people who often manually enter data.
Any time, a piece of paper is passed around or when people enter data manually you can either automate or improve the process. People are prone to errors.
Right now, I am rewriting a mission critical application, some trivial changes will save hours a week and improve the integrity of the information. It is not as exciting as writing algorithms but it is nice to see an application written by you used by 200+ people.
Honestly your best bet is to talk to people. I doubt cold calling/knocking on the door of a business will succeed, but people get enthusiastic when it comes to complaining about tedious/monotonous work. Especially at bars. Turn to someone nearby and say "I am looking for ideas to yadda yadda save people time and frustration. Is there any tedious process you deal with at work which you think doesn't need a person to deal with?" If you travel, this is especially common in airports. I've never asked someone this question and yet people rant at me all the time once I say "software developer".
You really need to find a domain expert who can at least get you started. I'm working on a problem that I would not have even known existed, if not for running across a couple of engineers who had a business in the field and saw an opening that only a small company would care about (market isn't big enough for the large players).
I know similar situations have to be all around us. The problem, as you say, is finding out about them.
At the moment many corporates are just automating the incoming invoice process. However, many processes are document (any kind of digital file) based to share information between departments, vendors or customers. Many processes could be automated. To identify a business case for automation worth coding such an application or offer an API we use three main KPI to identify processe worth automating it:
- more than 10 documents per day on year average, e.g a bank will receive new annual reports only in some calendar months but in massive scale
- average number of pages or lines of text per document, the longer the document the more mistakes will be made by humans, as they don't have the time to read everything in detail
- average pay of the FTE who is able to understand and process the document manually should be higher than the average pay of all employees in the company, to make sure the documents encapsulate business value
It's not a fixed set of KPI but helps us to sort out too narrow use cases.
By we I refer to the team behind my startup Konfuzio:
Small payback : on your English home page under "Operation of the software" > "Information security", there's one too many sentences:
> We set the highest standards both when creating the software and when processing your data. Both when creating the software and when processing your data we set the highest standards.
