Tag Archives: no code

Standard

Posted by

Posted on

November 18, 2023

Posted under

Uncategorized

Comments

Leave a comment

“RKODE Boot Camp”

If you’re in tech and you have friends outside our industry, you are probably regularly asked some flavor of the question, “how do I do what you do?”, which is usually a question regarding high pay, freedom of work location, what I would call an “adult” level of trust from your colleagues and superiors, and flexibility in how you get the work done, among other benefits. There is no magic to working in tech; if you want to use your brain without needing an advanced degree, it’s a great way to get paid and survive, and maybe even buy a house and retire some day. For many it is a position of privilege that enables getting there – for me that was absolutely the case, which is a discussion better in person than on a public blog post. Furthermore, the way to “get a tech job” evolves all the time – the path I took would not look the same today.

Recently my partner was asking more seriously about what a path like this could look like, and asked somewhat rhetorically, “Should I just go to a code school?” And I have pretty strong negative feelings on that. The ONE code school that I used to think was pretty decent has also really disappointed me in the last few years. In my opinion, the folks that will get a job and stay in industry for more than a year or two would have done so without the expense and unaccredited/ever-changing program of a code school. Saliently, you cannot earn as an instructor for a boot camp/code school (interchangeably in this blog) what you can earn in industry. I can think of a dozen people who did these programs whose instructors suddenly dropped in the middle of a term, because they were doing the job while applying to software roles. I used to tell folks to check if the instructors had themselves graduated from the code school they were teaching at, which tells me whether or not the code school is teaching you to perform this program, or actually learn practices for industry.

So! What to do? I’m self-taught, with one code class that I took at the beginning of my journey in 2013. After the course was over, a woman fellow student recommended PyLadies, and I made the decision to go every Saturday and work on my projects and publish blog posts on what I was learning every week, and I did that for a year while I was finishing my degree in French and minor in Mathematics. That led to a weird little internship, which then led to 18mo in Support Engineering at a server config management company, which then, roundaboutedly, led to five years at my old company and three years in my current company as an operations engineer/devops engineer/site reliability engineer (these terms evolve), a space I’ve now inhabited since 2016 over a few roles. So I do think there is real possibility in a background, but consistent, learning toward a tech role, but I find myself frustrated by just how much money that seems to cost. With that in mind, I started punching up what I think would give you a base on which to seek out and competently interview for for entry level technical roles – junior software engineer, technical support engineer (emphasis on technical), IT desk/service, and more.

Language – pick ONE!

Lots to choose from but below is the list I think one could pick from and stick with – don’t bounce around too much once you’ve chosen. It’s important to learn deeply before casting your net too widely. Once you can read one language and make out its control flow reliably, you really can read most any language, and starting to work in a different language is really not too bad. You will find yourself forever comparing a new language’s paradigm to what you already know, so you want to make your first mental model strong. I started with Python and have seen it used from frontend to backend to personal scripting to simple data management, I have learned some C/C++ and boy oh boy can you get paid big bucks for being able to navigate its ancient and hallowed nooks and crannies well, JavaScript and Typescript are foundational and critical for web development, and Java is just ubiquitous. Describing these languages beyond this very brief sketch is outside the scope of this already monster-sized blog post. If there is another language that you are strongly considering that is not on this list, go for it! Learn it deeply. I think the program I’ve developed could very much be applied to many other languages as well, I just think that the five I’ve listed are terrific ones for beginners.

JavaScript, Typescript, C++, Java, Python

Who is this for?

I’m thinking of the adult professionals who can enjoy reading for its own sake and who are motivated to spend a couple hours a week – maybe more if you get really into something. Have you really enjoyed figuring out some piece of Excel automation? Have you gotten really into managing your own workflow, or improved upon/created effective, repeatable, teachable systems for getting some piece of work done? Have you, on your own, decided to pick up and complete a non-fiction book without external pressure? Do you enjoy engaging people on complex topics? If the answer to a couple of these is yes, I think you’d probably do well in a program like this and in this line of work, such as that can be hundreds of kinds of roles.

You’ll need a computer. You don’t need anything fancy, genuinely. A mac is probably best, but you can find used ones between 3-8 years old that will still work for a while, but a windows computer will work fine too. With Windows 10, you can use the Windows Subsystem for Linux 2, or WSL 2 for a real Linux command line. Personally I have not yet stumped my WSL 2 install with anything I’ve tried to do – python, bash, docker, rust, etc. If you would like to pursue a Powershell and native Windows based programming career, this isn’t really the blog for you, and I don’t think I’m the person to advise you on it, but godspeed!

The Program

Finally we come to the program itself that I jotted down one evening about a week ago, and keep chewing on as what I think could really get you a job in 6-9 months, for very little money – a fraction of a fraction of the cost of a code school. And if you get to the end (spoiler: the last one is “take a class at your community college”) and have decided it’s not for you, the money you’ll be out is the cost of a few books, NOT $30,000 or whatever they’re trying to charge these days.

  1. Join the main language’s slack or discord. Join the beginners channel, and pick five other channels to follow and keep up with. Make one of them social, and join conversation a couple times a week. If the channels aren’t active, pick new ones. Come up with a technical question to ask at least once a week in your learnings. Try to answer other newbie questions. This will be part of your learning experience for the rest of this program.
  2. Optional: a codecademy (or comparable free) class on one of the recommended languages
  3. One beginning programming book with exercises
  4. 3-5 videos and exercises on Git and version control
  5. PROJECT: Spend two weeks building something with what you learned. Feel free to liberally crib from the book you selected in step 3!
  6. One beginning HTML and CSS book with exercises 
  7. PROJECT: Spend two weeks building a local website with just html/css. Cribbing rules apply.
  8. One beginning systems or networking or ops or AWS book (not azure and not gcp)
  9. Optional but highly recommended: bash and Linux command line basics
  10. The Phoenix Project book
  11. Forge Your Future with Open Source book
  12. A second and more specialized programming book which contains exercises in the same language you chose above
  13. PROJECT: Spend two to three weeks building a project based on the specialized book you read.
  14. Workshop a larger idea* for a project, which will require your language of choice and html/css. Find a collaborator from your slack. Work on it for six weeks. Scoping this can be hard, but your new colleagues and your collaborator can work on this with you.  *If your language is c++, skip the html/css aspect.
  15. A community college course in your chosen language
  16. Stay active in the slack, start building a resume of projects with old jobs relegated to 1-2 lines each.

“But why this and not that?”

There are some pretty opinionated recommendations in the above list! My intention is not to offend but to offer my professional perspective. I really think you can throw a dart and find a perfectly good book to learn with, and as you develop and make connections with people, you’ll find the books you want to read on these topics. They can’t DRM you out of your own physical book, either. If you prefer e-reading or audiobooks (probably a little harder for hands-on computer learning but not to be discounted and plenty powerful still!), please feel free. Personally, I like to have the paper book, and find it’s harder to ignore than a PDF in yet another browser tab, competing for my attention with social media and whatever else I’m looking at at the moment. This isn’t a program I am administering, it is a set of guidelines I am recommending.

I feel that Git is something that is best suited to personal instruction, so instead of videos, you could ask a friend in your new slack for an intro if that is appropriate, or honestly if you’ve read this far and you’re still interested, I will try to make time for this for you, the reader!

If you’re going to learn a cloud hosting system, just learn AWS. GCP and Azure exist, but the ideas are the same so using a different one after learning a bit about AWS is not too big a lift. AWS is used all over and defined the game. Just be careful with the free tier if/when you start making infrastructure on there.

I think that this curriculum is missing an introduction to databases, and I really welcome your feedback on where that would fit in this setup.

The Phoenix Project and Forge Your Future might seem like odd items out in this list. However, TPP is a business of technology book that is well written and exciting and ~fictionalized, and the insights it offers are innumerable and years later, I find myself thinking about it and recommending it. Forge Your Future with Open Source is a how-to for getting involved with Open Source, which is a common but challenging recommendation for newbies, and this book explains and demystifies – and justifies! – how and why to get involved at this level.

Don’t sleep on the slack. Seriously, do not proceed without step 1! Join the language slack, get involved, get to know people, make it part of your community and your life and this program. You will not get a job if you don’t make friends in this network of people. Folks hire their friends. If you’re a beginner, you simply will not get a job over someone else if you are a total unknown. Once you have the resume, this will be less (or differently) important, but you probably don’t yet, so it’s time to add to the rich community of this language with your awesomeness! And you’ll be adding as much as you are receiving! Look for other questions to answer, ways to help, volunteer opportunities, and the “payoff” in lifetime connections and strength of networking will be utterly invaluable.

Thanks for reading! Please comment and let me know what you think! You can also email me at bootcamp at rkode dot com if you would prefer.

Standard

Posted by

Posted on

June 26, 2022

Posted under

Uncategorized

Comments

11 Comments

Technical Onboarding information category

Hey folks, been a while on the main blog. Got lots of stuff I’d like to talk about here at some point (like getting off twitter via buying another WP blog)! The one for today is borne of some work onboarding I’m doing for a new person on the other side of the world from me, which brings endless fascinating challenges, basically all of them good!! Was talking with my PyLadies besties (six of us ran the portland pyladies chapter for a few years and we have all stayed close) and we got to some interesting places as far as technical (and possibly other kinds that I can’t speak to) onboarding.

As I see it, there are four categories of information relevant to a new engineer*.

  1. What I expect you to bring to this role
  2. What I expect you to absorb and internalize *without* documentation
  3. What I expect you to read and reference from documented internal sources
  4. What is undocumented but which should be documented.

You’ll notice that three of these are pretty straightforward. Or at least, ideally they would be. Regarding item 1, what I expect you to bring to this role should be clearly laid out in the job req, and in our case in Data Center Provisioning, we wanted them to have strong networking, decent general command line ability (this can be switch-specific though – switches, like Cisco network switches and Arista network switches, and others, have their own structure that is NOT filesystem tree based, but which is somewhat cross applicable to ~Linux command line interfaces, which is my familiarity), virtualization experience, a little scripting, and if you have cloud ops experience and some programming, that’s a bonus.

Re the third (we’ll come back to the second), what I expect you to read and reference from documented internal sources is never as grand as you want it to be! It isn’t that we don’t have a ton of docs – we do, but as anyone in this field knows, it is a monumental task to keep it updated and constantly added to in relevant, searchable ways. We do our best and are always trying to come up with ways to incorporate this work into a regular cadence of attention and discussion.

Which brings me to our fourth category, what’s not documented but should be. This is a huge category, and it’s absolutely fuzzy with the second category! There is so much that I can CLEARLY state that should be documented, though, so even though there is gray area, there is such a huge quantity that is utterly black and white.

Finally, the category of what I expect you learn and internalize *without* documentation. I bristled at the idea of this earlier on in my career. Now, I am pretty sure that this is the secret sauce of any technical role, maybe any role period, and I believe that my success as a colleague-trainer depends upon clarifying this category over all others. The clearest examples of things in this category are, like, (in my field anyway) how to use code repositories, including how to submit your code for review and how to generally use a cloud remote tool like Github (that’s probably a pretty odd label for what GH is.. please forgive it). These are the kinds of things you would explicitly show a junior level person, or someone whose background is ENTIRELY networking or physical racking-and-stacking in datacenters, but at my job we generally expect that you have this.

The less clear pieces are harder to describe (no kidding lol). I think this is ultimately the category of company/job specific knowledge, that as you deepen your understanding, hopefully gives you tools and knowledge for future career as well. Some of this is historical context for your job, that you don’t really get until you’ve been there for a minute. The context that I have, having been at Fastly for 18mo now (not a long time but more than a flash in the pan), is a key part of the value that I bring, and the longer I’m in this job, the more valuable that will be (but not necessarily – there is an upper limit that is probably worth exploring in a “should you move on from your job” kind of post). Another piece might be, at least in my case, the unique design of what we build. Not going to get too specific in a public blog post of course, and while you can learn design generalities for what we do and make and provide, the specifics of our builds will not be known until you develop some working, repetitive knowledge. And then it will change subtly, over and over and over!

“But wait, Rachel, shouldn’t this stuff be documented?” This question is basically THE reason I felt the need to write this blog post. The answer to some of it is yes! The answer to a LOT of it is, “uh… kinda?” Like, yes, we have design docs, which are thoughtfully created and introduced to the relevant teams! And they apply to one version of it, or maybe one category of versions of it. But this one is different for pretty good reasons, and you can tell by looking at X and Y. And this other one is different for reasons we later discovered aren’t very good, and you can kiiiinda tell by looking at Z or W! I hope this is not too abstract. I’d like to get to a place where I can really define this category.

I think this second category is also partially the reflection of the fact that we simply cannot document everything. It’s not possible, and further, we got work to do folks! One of the common personal aphorisms I return to is that they’ve hired us here for our brains. This, and my last job, are not widget jobs, like my support engineer job from 2014-2016, which was extremely technical and demanding, but which 90% depended on a) ticket inflow and b) having TOO MUCH ticket inflow in order to never “overstaff” in this “loss-leader” department (a characterization I find short-sighted and even cruel – can you tell my feelings on this with what I’m putting in scare-quotes??). They need us to be finding and solving the continual edge-cases we encounter before they become major incidents or otherwise impede the function of our organization… and we are very lucky to be able to do that. Sometimes we’ll all gripe about some bizarre complexity or a decision handed down to us from a few levels up, but really, we’re all just trying to solve technical AND business problems, and it’s genuinely a rare and special thing to be given the freedom and the salary to do so with as much of your brain as you care to engage.

Quick side bar, I do think that a very technical job (to a point!! no ocean-boiling, that’s burnout territory) where you really are trying to solve problems and get shit done a little better each time, is rather a fountain of youth. Keep your brain sharp and you keep dementia at bay a bit better! No guarantees in this world of ours but cognitive function is a real thing that declines and like any muscle, the way to keep it going is to USE it!

So. Getting back to the categories of onboarding information… What do we do with this? Well, I’m working with it as we speak, and it’s HARD! It’s a bit know-it-when-I-see-it, and part of trying to write all this out was to personally try to be able to recognize the “second category” of information a little faster, so I can impart it better, so our newest engineer can internalize it more easily, so we don’t fall into the trap of trying to document something like “and then, type cd foldername…..”. And of course, the point of it all is to prepare our newest engineers on our team in the best possible way we can for themselves and for our organization!

Truly I’d LOVE to hear what you think about these categories, and if this reminds you of Some Book (or blog post!) I Should Read, please let me know!

* this isn't the place to discuss coder/programmer/sysadmin/noc/etc all having the title of engineer, it's fine, your opinion probably isn't wrong even if we don't agree, just not going to talk about it here.
Standard

Posted by

Posted on

October 20, 2014

Posted under

Uncategorized

Comments

Leave a comment

Employment and Education

Hello friends! TIME HAS PASSED. But here you are again! This day finds me employed, after a long struggle. Really, I’ve been job-seeking since January, though well in advance of when I needed to, as my graduation date was March of this year. Believe me, I am still fuzzily post-graduation, extremely happy to have no far less homework than while earning my degree (en français, bien sûr !).

Understanding that confirmation bias makes fools of us all, about two months ago I changed my resume (do I write résumé? seems soooo new yorker snobbish, though it is correct) in what may have been a crucial way. My tech recruiter friend gave me some terrific and honest (read: intense) feedback on my R/CL and told me to cut out the “References available upon request” line, because duh, everybody knows that and it just takes up space. For a few weeks, I had it removed entirely. Then, I did something rather bold, and added the following snake-oil-style pitch toward the bottom of my cover letter:

“But don’t take my word for it! Just ask person_1, the leader of the free world, or person_2, the founder of Mars, or even person_3, the inventor of Post-Its! Every one of these folks is happy to -brag about- be a reference for me, so please, contact them!”

And I got a call, from an awesome company that I have always been too afraid of applying to, thinking that the folks that work there are a special kind of brilliant & that I wouldn’t have a chance in hell at actually working there. One of the reasons, other than my qualifications, that they said they called, was because of one of those people who I’d listed in that section.

Typically, references are a very late game process in the hiring world. Why bother calling references, a time-consuming and very personal (and personalizing!) process, if your candidate hasn’t even made it through a phone screen and an interview or two? In other words – why call references unless everybody is serious? But the fact that I put a few folks on there who wanted to vouch for me made a huge difference. And Portland is really so small and the scene is so focused that the names are fairly well-known. That wasn’t an accident, but I met these great people naturally, by getting out, participating quite heavily (and earnestly!) in PyLadies, and making friends with the people around me.

After two phone interviews, a task, an all-day interview, and a few (totally transparent!) hiccups, I was offered the job at Puppet Labs as a support engineer, and I feel so lucky, I have to keep from gushing about it. I left my stable, lifer career nearly four years ago to do ambiguously Better, and yes, Virginia, this is Better.

SO! Now I am LEARNING, learning learning learning! I’m still having a hard time reading the tickets that come in, but what I am able to do is parse Puppet code, and explain what it is and does, and how it’s an enormous, Neil Armstrong-style leap over previous (and still very widely used!) server management technologies. I’m pretty sure I’m in the right industry, guys, as this is really cool to me. Puppet is a company I am extremely excited to work for, for many reasons, not the least of which is getting to know the complex, technical, and awesome product. I keep a notebook on what I’m learning, and I fill several pages a day. Future blog posts will probably just focus on Puppet stuff, unless I get a chance to work on some recreational stuff. Woo-hoo!

And one last thing: if you know me, you know my absolute most highly recommended piece of advice to those looking for jobs: start a blog. Start a blog, start a blog, start a blog. Don’t wait til you code every bit by hand, don’t wait til everything is Perfect, just go to wordpress or blogspot or whatever, and start a blog. Nearly everyone I’ve interviewed with has mentioned it. Fear not about seeming stupid, because you’re brilliant.

Ok – going to cut this off before I get weepy/proselytizey/we-are-the-world-y. GOOD THING.

Standard

Posted by

Posted on

September 11, 2014

Posted under

git

Comments

Leave a comment

Aspirations toward Gittry

Over the last month, we’ve been working hard to finish up the coding and environment for, and finally the filming of, a series of tutorial videos. It’s something we’ve been working on at my job since, solidly, May, and but for a few release-based loose ends (“will our requirements.txt file really work with pip? why isn’t it working over … THERE?” etc etc), the project is over, and my contract is coming to a close. So I have a few projects I’d like to work on, AND NATURALLY, document for you!

First, let me point you to my website, which I have hugely upgraded. I’ve got a style sheet which I first applied just to the main page, then I applied it to the resume which I also updated, a bit, though it’s difficult since each position I apply for has a subtly different set of information.
therachelkelly.com
Regardless, I’m proud of the small, attractive changes I’ve made. Next up is to get a handle on some bootstrap and cherry-pick pieces of it, like the nav bar and a few other nice ideas.

Next, I’d like to run through another codecademy class, maybe the advanced web design one, but what’s more likely is the API-manipulation course. At some point soon I’d like to begin a project where I get a couple of the open APIs out there to talk to each other. My intention is not to re-invent the wheel, but to get a look at its inner workings myself!

I’m also about 60 pages through Jon Loeliger and Matthew McCullough’s Version Control with Git, 2nd ed, which is only about a year old, so quite up to date. As I’ve said, I want to be a Git wizard, and to earn that pointy, star-covered hat, it’s time to take a deep dive. It’s extremely exciting to me that I can read this book – when he (it seems like it’s mostly Loeliger’s game) says “The first number, 100644, represents the file attributes of the object… [and] should be familiar to anyone who has used the Unix chmod command.” which I am! I am familiar with chmod, Unix, and so much more relating to this topic! Wow! This is not to say that chmod is a particularly difficult concept, but that it is NOT a terribly entry-level topic either – I am rather beyond entry-level knowledge for many topics, and that is enormously gratifying.

brief aside: chmod refers to the the command which determines the level of permissions of a given file or directory. go here for more information. want to write more on this in the future, because I still haven’t found a super terse explanation.

…

So this Git book is great. They’ve already referenced someone that I KNOW, so that’s charming and a bit surreal. I suppose living in (the extremely small town of) Portland and being as active in the communit(y/ies) as I am, it’s bound to happen that I’ll meet or already know some People. But on to it – the book practically begins with SHA1 numbers, the hash number that Git assigns to a unique commit. Did you know that if your file is named yourfile and it says the same thing that my file, also called yourfile, says, then the SHA1 will be identical? WILD. Mind = blown. Apparently there is (very infrequently) a concern of “collision,” or two different kinds of commits yielding the same hash, but as the SHA1 has approximately 2^160 permutations (pretty sure I can’t use that word here?), that’s pretty unlikely.

So for now, the plan is to write about whatever I’m learning in the Git book, because the Git book is awesome. SEE YOU NEXT TIME!

Standard

Posted by

Posted on

June 22, 2014

Posted under

feminism, javascript

Comments

Leave a comment

Javascript first thoughts, mackatoots, & tutorialino

Hello again! I have been working and working and working, lately, and I have a few things up my sleeve!

First, my company, The Open Bastion, is working on tutorials in Python. Get in touch if you’d like to create with us! Note: paying gig 🙂

Next, though I know some Python, it seems that I need to keep going, so I am learning Javascript, now. Exciting! Something altogether new! So far, it seems like a friendyfriendly C analogue, based on the 50-odd pages of a C++ book I read back in the day, which makes web site and app creation a BREEZE. I know complications will come – I feel like I hear more complaints about Javascript than any other language, right now, but as with all new languages, I’m really enjoying learning the syntax. I’m doing the Codecademy interactive tutorial and it’s adorable and fast fast fast, so I feel like I am getting a lot done and learning learning! Note to self (and to youuuu!) to research later – why are semicolons sometimes required at the ends of lines & sometimes not? I wonder – is it more than just good style? With Cx semicolons are quite explicitly required, right?

Next, I’m working on a Mac, now. If you know me, you’ll know that this is, like, a huge deal for me. It’s just a work machine, AND it’s four years old, buuuuut it’s great for coding even if it’s comically bad at other things, i.e. file management (honestly does anybody EFFECTIVELY use Finder? my theory is that apple wanted to ensure that their file management system was different than windows’ [whose Explorer {directories, not internet} is superior to all others] and now they’re too bashful to back out???). The mouse pad, though, is a serious delight to use, the best touch pad I have ever operated on, and the keys are lovely to type on. It’s strange having no optical drive (it’s an Air) and the minimal number of USB ports can be frustrating, but of course, a $1300 machine is a $1300 machine, and a professional versus hobbyist (read: my perfectly delightful $600 2.5y/o windows/ubuntu machine) computer is going to be a vastly different user experience. I hate the fanboyism around macintoshes so, so much, though, that I probably will still never buy one on my own, but it seems you need to be comfortable with them to work in tech, at least in Portland. So here I am. A bit blech, a bit “oh this works really well.”

Lastly, I’m volunteering with a group called Chick Tech right now, which assigns mentors in industry to young women. It’s a very cool organization, and I can already see myself staying involved with them for a long time. I worry about this approach to solving one of tech’s many diversity problems, though – the problem, at this point, is not to interest young women in STEM, but to keep grown, adult women in tech once we are here. And here, we are, and I/we will demand equality. Jessica McKellar and Selena Deckelmann, a couple of fabulous tech luminaries whom I follow, both refer to the “leaky pipeline*,” – we can get them in, but we can’t keep them there. I think the following tweet from Jenny Thurman sums up the issue quite well.

So I will continue to think about this while I have a blast with my mentee, a motivated young lady whose trajectory I am excited to follow and encourage.

* the earliest reference I have found to this particular use of this term is from a paper from 1996, found here.

Standard

Posted by

Posted on

December 31, 2013

Posted under

Uncategorized

Comments

1 Comment

EOY Recap and 2014 Goals

I love end of year posts, like Scalzi’s and probably others whose blogs I do actually read but can’t think of, ha ha! This has been the year of transferring my nerdiness to generic pop-culture things like reading a ton of scifi and guzzling Star Trek, Doctor Who, Firefly, etc, to some real gritty stuff like some actual facility with computer systems. Very exciting.

I have made a zillion miles of progress and Big Life Decisions this year, and programming-wise, were and are incredibly impactful. My goal that I have been working toward for the last few years has been to teach high school math, I figure I have enough of an aptitude and teenagers are (don’t panic!) actually pretty cool to work with. And I knew I needed to be studying toward something that would get me an actual, adult, non-entry-level job, the contrast to which I worked in for four years, and let me tell you, hearing “well, we think you do deserve a raise, but there’s just no money” is pretty hard to hear/believe when you work for one of the biggest and most successful companies in the world, earning record profits quarter after quarter even in the most difficult of times (see 2009, when I saw coworkers’ 401(k)s slashed to 20-40% of what they had been).

Rant over, getting back to it, part of the coursework for the high school math teaching program at one of the graduate programs I was looking at included an introductory programming course. As I’ve mentioned elsewhere, this really struck me and I joined a ladies’ programming group and stuck with it. After hearing that one definition of a master is 10,000 hours of work put into it, I tried to come up with a figure of how much I’ve put into python and related projects, and I think I’m right around 250h, give or take. So I have a long way to go, but I’m very pleased with having allotted that much over the course of a year. It’s 250 more than I had by last year, and that’s the only metric that’s important right now!

And now, for your handy-dandy list-format of what I’ve started and accomplished this year, under the cut. Wahoo!

Continue reading →

Standard

Posted by

Posted on

November 2, 2013

Posted under

LPTHW, LRTHW

Comments

Leave a comment

Lesson 24 and thoughts

Last week, I completed lesson 24, which was a “make sure you know how to do x, y, and z” exercise of no new material – a fine cap to the no-new-exercises triad of 22, 23, and 24. I am, to be honest, super bored by the idea of not doing new things while going through these lessons and have sped through these fairly quickly.

I am already planning what I’ll do next, after LPTHW. Probably pre-emptive, but there is so much out there and it’s hard not to speculate what I’ll want to do next. I like Zed Shaw’s style and might do the Learn Ruby The Hard Way module, but I might do Learn You A Haskell for Great Good! next because a) Haskell is apparently very sexy right now, and b) it’s probably a good idea to go through a different kind of tutorial than just The Hard Way. Though Ruby might be more career-helpful if I should ever want to make something of this (fairly long-invested at this point!) hobby, so we shall see.

Onward!

Standard

Posted by

Posted on

October 19, 2013

Posted under

Lessons, LPTHW

Comments

2 Comments

Lessons 22 and 23

Ok! These were sorta boring! 22 said “go back over everything and make sure you know it,” essentially, and because I am impatient, I went through all the previous lessons in around an hour, surprised at how much I have actually absorbed. Then I moved speed-quick over to the 23rd exercise, which says to look up code and see if you can understand it, so I did a bit of that, and now I am again quite anxious to get back to regular lessons. : )