https://sysadmincasts.com/episodes/51-mechanics-of-building-...
https://sysadmincasts.com/episodes/51-mechanics-of-building-...
The son of a friend graduated from a CS degree last year and still doesn’t have a job. I told him if he wants to be a software developer, then he should just develop software, and showed him some scripts and games i’d written in Pythonista on my phone. Nobody has to give you permission. High quality dev frameworks can be got for free. You can run web apps on a free tier on Google or AWS web hosting. Developing mobile apps is easy these days and dev accounts with Google or Apple are very affordable. Get a GitHub account for your projects and build up some rep on Stack Overflow. You don’t even need to do anything super fancy or commercial, just interesting or fun or novel and demonstrate an understanding of a range of technologies. Put links to all of these on your resume.
Set yourself objectives. 4 months to get a web app running on Google App Engine (you can get a tutorial app working in an afternoon!). A month to figure out Github and upload it, and do this for future projects. 2 months to port it to AWS. 4 months to get an app into the Play Store, or App Store. All this can be done in spare time, half the time following tutorials and the rest on whatever your apps do.
Companies want employees who are self-starting autodidacts.
Any mol-bio lab has seen one of these guys around: https://www.sutter.com/MICROPIPETTE/p-97.html
Anyone that has had to pull tips knows how much it sucks. It takes dozens of glasses to finally get all the parameters working well, and that takes an hour minimum. After all that, you then get to start the experiments. And then a storm comes through and messes with the pressure and humidity and all the parameters are wrong again.
So, if the OP could program a calculator-thingy that takes in current conditions, some parameters specific to your lab and your puller, what you want the resistance and tip angle to be, and then spits out a set of numbers to program the puller, that would be SO USEFUL! I'm not saying that I want the exact numbers, but I'd like a pretty good range of them.
I transitioned careers to programming when I was 28, and my first 2 jobs were in finance. I dgaf about finance and didn't understand it at all. Made it far, far more difficult for me than it otherwise would have been.
My older brother taught himself to program at 36. He was a 3D artist before, he had four kids and a wife and a full time job. He spent evenings and weekends building things for his wife's interest in photography and started blogging about his experience learning. He now runs a very successful company and completely changed his life inside of 3 years. He's not the best programmer, but he focused on the work and the assets that he had that were different from people who might be the "best" programmers, that edge is a huge asset.
I've been programming since I was 12 so it's hard for me to fully relate to starting new. Now at 35, I think the thing that people thinking programming is hard later comes from thinking of it like learning to paint or something. One unique aspect about programming is that it's a force multiplier. Once you grasp something, you don't need to reproduce it, you have it and you use it to prop up the next thing.
I'm biased towards python, but experience tells me it's one of the best starter languages because of it's flexibility. Whatever you're working on will always need a web portal, Django[1] is amazing. You can get started quick and python will allow you to do whatever crazy thing you dream up as well.
----
I've done a reasonable amount of programming mentoring and four things I've found about having limited time to immerse are:
1) Do things you think are fun! It doesn't matter if it's "relevant" to your track, learning to make it play is vital.
2) Give yourself easy wins early and often. If you find yourself stressing about not getting something, put it down and find a way to get something out quick. Once you have a win, take that new confidence back to your rudiments.
3) Never underestimate documenting your process and sharing it. Blog, draw your problems on paper and in a graphics tool, and keep a physical journal.
4) Try to wrap your head around that the feeling you have now about not knowing IS the state of being a programmer. As you get down the road you will be moving into the exact same state with a new "bigger" things. Something that does change is being able to tab into the sense of discovery and wonder easily. Enjoy it!
I believe in you! You got this!
[0] https://www.fabfile.org/ [1] https://www.djangoproject.com/