Header Image -

Spring Adventures

by dave

The lack of posting here should not imply a lack of adventures this spring…

I have been out exploring the areas around Milford, UT, bringing home some obsidian, and a few other shiny things. The entire family spent a day collecting crystals out near Marysvale… the kids mostly found chunks of Selenite, but they were big and shiny so it made everyone happy. I found some rocks that had obsidian mixed up with sandstone, something blue/grey, and flecks of gold. I’ve never seen anything quite like it, and there was not much of it, but in my non-expert opinion, it is pretty cool.

The kids and I also explored old back roads between Eureka and Delta, and found some promising areas to come back to in the future, when we want to spend a longer time at a single site, really digging for treasures.

End of Year 2015

by dave

Cliched thought it may be, I set goals for myself in 2015, and although there is still almost 2 weeks left in the year, it is close enough to see how I did:

  • Succeed at work. 
    • Did I succeed this year? Well, I didn’t fail. We delivered on projects. We have a vision for the future.  But I can’t claim anything extraordinary.
  • Get Healthier
    • Yes, but it is just the first step on what is hopefully a long journey.  Most of the year was spent talking to doctors and laying around in pain. We made some progress in the early winter, and I now am only in pain a couple nights a week. I am just now starting to lose weight and exercise again. But there are still some things wrong and not as of yet diagnosed.
  • Rekindle my creative efforts
    • Again, some success – I started painting again. Drawing, too. I have all the tools and supplies I need. We have my artwork hanging on the walls of our home, that was created this year. The only missing piece is the audience. I have not developed anything that I yet feel is worth submitting to any shows.
  • Succeed on the farm
    • We have a larger chicken flock, are inundated in eggs and dairy, and produced some honey and produce. We bred goats, and have 3 goats worth of meat in our freezer. Well maybe 2 – we have eaten some of it. We know what we need to do over the winter to increase our production next year. I’m calling this one a success.
  • Spend more time with children – restart the one-on-one talks and nights out that I did with my kinds in 2013.
    • I now have nightly talks with each child. We have gone out exploring the world multiple times. I have enough energy to do more around the house, and have taught how to do chores more efficiently, which means we spend more time working together.

I believe we can call 2015 a good year. Not an amazing year, but good enough.

2016 is more of the same:

  • Work – Either succeed or fail, decisively. Breaking my normal rules against talking about work, my company has hit a milestone that should allow us to all do amazing work this year. We should be able to grow and have a great year. My goal is to actually do so. However, if that goal fails to happen, it may be time to move on to something else, as it means that either I’m not doing as well as I can, or something out of my control is stifling the potential.
  • Health – I want to get to the point that I can exercise again. I want 2016 to end with me able to go on hikes, and be at least smaller than as I was when I left my last full-time office job.
  • Creativity – I want to keep painting and drawing, but also be more serious about photography, either as a final creative product, or to provide source materials for paintings and drawings. I also am going to start trying to do more serious writing, and improving my abilities as a writer instead of just being a guy who does blog posts once in a while.
  • Farm – Simple goals – get irrigation systems in for all garden boxes and fruit trees, keep the gardens weeded and watered, and have a non-trivial produce harvest in addition to our current production.
  • Family – Simply have a  happier and healthier family at the end of 2016 than we do at the end of 2015.

 

Learning to Code

by dave

I am surrounded by conversations recently about learning how to code, and wanted to write out some aspects of my journey to being a coder…

The Apple ][

When I was a kid, my dad got an Apple ][ at his office. And on some Saturdays, I would go in and play with it. I had nothing but the manual that came with it, so I pretty much would load up BASIC and start coding the same kinds of things every Saturday. I would write basic loops, counting from 1 to infinity, then enjoying making it overflow. I moved on to random number generation, and would write up basic programs to pick a random color and place it on the screen in random locations, then I figured out how to do the same in high resolution. There is something meditative about watching a screen fill randomly.

The Apple also had DBase on it, so I played with that a little bit and learned how to build a database. But I did not have a reason to build a database as a young boy, so while it made complete sense to me, I could not think of why it would be useful.

But then I hit a wall – I remember thinking that I wanted to learn more, but I did not have resources to help me. There were professional programmers in my town, but they worked in FORTRAN at the insurance company my mom worked at, and she did not think that they would want to take on a child to teach them more. In hindsight, I’m not so sure that was true, but that is about where my childhood programming career ended.

Although I did not do anything truly impressive in those days, I did learn some of the basics of how to code – variables, loops, input, output.

Logic Puzzles

Logic puzzles have nothing to do with technology, but I credit them for much of my ability to think analytically. If you are not familiar with  them, there are books available, or you can generate them online at: http://www.logic-puzzles.org/

I had a large book of these as a kid, and over what felt like years,  but may have just been a summer, I worked my way through that book, eventually completing all but the hardest puzzles.

Aside from the basic logic skills, I believe this helped me to know how to visualize data, and relationships of data points to each other. This is a skill that I find very useful as a professional coder. All coders  can walk through code, understanding the instructions and making code do what it is supposed to do. But all code eventually needs refactoring, as the usage of the code and the related business evolves and changes. Being able to visualize representations of a codebase in your mind lets you better break it into components, understand how they all relate to each other, and see ways to re-organize code into better structures.

Writing a Video Game

I failed to write a game when I was in 7th grade. I would go to the library and play games on their computer, and continue to play on computers at my dad’s office, but wanted to try to figure out how to create my own games. This continues to be a popular reason for learning to code, event today.

Without any resources to learn from, and knowing only the basics of coding, I utterly failed. I drew something on the screen, then wasn’t sure how to animate it. I could draw a background on the screen, but had no graphics frameworks, so I just wrote each pixel. I simply did not know what to do, and had no resources to help. So I failed.

But I did realize that there was a lot more to creating significant work than just what I had learned. At least at this point, I realized what I did not know, which is a great starting point for learning something new.

High School

In high school, I did little with coding. I was a teenager, so I did the things teenagers do — video games, sports, lots of bike rides, time with friends, etc.

I played with computers more on the hardware side -learned how they were built, how all the components actually worked. The one coding project I recall doing was when I figured out how to directly control the pins on a dot matrix printers, and started sending it specific pin instructions to draw images. It was tedious and painful.

College

I took no computer science courses in college. I had this crazy idea that I should study topics that I could not teach myself, so I studied fine arts and philosophy.

In hindsight, this was an excellent decision for someone who wants to be a coder. It is not the only path, of course, but it was quite effective.

Fine Arts is an excellent background for coding. Although the thinking is completely different, the creative process is exactly the same. You need to have a vision of what you want to create, determine the best methods to reach that vision, plan how to create your work, and actually start the work and execute that plan. You need to develop skills in whichever medium you are using, and know what tools are correct for which jobs. These same principles directly apply to coding.

Philosophy teaches you to understand the core goals of a project – in philosophy, you are normally trying to answer a question or prove a point of some kind. You critically evaluate the premises building up to your conclusions, you can argue for or against most points, and decide what answers to accept/reject, to help build you towards a logical conclusion that holds together. Again, this is like unto coding. You are building logical pieces up, to reach a goal. You make critical decisions on the best way to reach that goal, and implement them in code.

In general, a liberal arts education teaches you a process – how to deconstruct anything, but more importantly, how to pull the best parts back together, and build your concepts back up into something better than where you started.

That reconstruction process is one of the most important skills that I have. Anyone can tear something down, but the ability to improve it as you build it back up seems rare.

Oh, and I ran computer labs for my college, too. *shrug*

Early Career – Support Roles

The first few years of my career was all about tech support – doing direct deskside support at IBM Research, sysadmin work at IT research firms who eventually grew into Gartner Group, stuff like that.

At those positions, I learned Lotus Notes. Although it is a dying technology today (that people mock), in those days it was good stuff. We could whip out a database with forms, UI, data views, without knowing how to code. We could replicate data to different clients, and used it to publish our research. It has not aged well, but it was my first exposure to building an application to handle what a business needed.

It is important to note that I was building simple applications at this point in my career, before I even knew how to code. Although coding is the most common tool for building business solutions, it is not the only tool. It is important to know what tools are available to you, and use what you have to the best of its ability before ever writing a line of new code.

Transitioning to Coding

I was a full time application developer and team lead, before I ever knew how to code.

I worked as a consultant for IBM during their rollout of Lotus Notes after they purchased Lotus.  Although my job description was for deskside support, due to my prior experience, I knew more about the product than most IBMers. I became involved in the rollout, and quickly started helping people understand what could be done with the product.

My boss hired me on full-time, as gave me a team lead role to focus solely on building out applications for that division of IBM, including training some of my team members on how to do the same. I built a team of 4 developers, and started holding training sessions for other application developers throughout the division.

I still did not know how to code…. but soon learned. IBM/Lotus added a real coding language to the product. Well, at least real enough for our purposes. LotusScript was added in version 4. It was based on BASIC, but added an object model that opened up the capabilities of the product.

So now was the time that I actually learned to code. The learning curve was steep, even though I had the base analytical and logical abilities, with some solid application development experience under my belt. It is like learning a new language. You know exactly what is supposed to happen, but have to learn how to express that in the way your computer understands. The first time you go through this process, it takes time and effort.

My learning process was a top-down approach. I would do as much as the system allowed before coding, then learn how to code one specific task. In that way, I eventually worked through the commonly used objects, method, and functions. It really only took a few months of work to make the leap to actually coding.

Once you make that leap, and no longer need to look at the help or reference books for every line of code, you are working the way most professional coders work. We do not know everything off the top of our heads, and with the speed of searching online, we don’t need to. The code that you use all the time becomes as easy as speaking English, and you just pull up references when you forget the exact syntax or parameters for uncommon functions.

Conclusion

At this point, the story is done. I knew how to code. I was not good at it yet – that is a different process and a different story, and a story without an end.  But if I could tell anyone learning to code one thing, it is that the actual coding is just the cherry on top of a larger sundae. It is the logical and analytical thought, the ability to deconstruct and reconstruct concepts, and the ability to design not only the final result you desire, but the structure to get you there… those are the key components to being able to successfully build applications or other systems.

Perseids

by dave

A couple nights ago, the Perseid meteor shower peaked. On a cloudy, rainy day. But as the sun went down, the clouds cleared to the west. So we drove out to Utah Lake.

It was full of bugs, and not the best place for stargazing, but we did lay down, stare at the night sky for an hour or so, and watch some meteors go by. There was only one great bug impressive meteor, but many smalls ones. And the Milky Way was visible.

We got home very late, with just over 66% of the children falling asleep during the 15 minutes drive back to the house. And everyone slept in the next morning.

 

 

No Adventures in Weeks?

by dave

It is true, the adventures stopped for a while. Mostly due to heat. Utah is a desert climate, mostly. Summers are the wrong time to be running around. Spring and Fall… those are adventure times.

So for the next 5 weeks, I’m choosing to increase my focus on work. The farm is stable, my other goings-ons in my life are slowing, and it is too hot to do much outside. So I’m hoping for a high-productivity period here for a few weeks.

So what does high productivity really look like as a work-from-home developer?  It doesn’t mean 16 hour coding sessions, 7 days a week, at least not for me. But it does mean more short coding sessions in a day. Instead of coding most of the standard work day, then signing off until the next day, a potential work day could go something like: Get up, do my morning ramp-up routine, code a feature, go for a walk, code another feature, have lunch with kids, code a feature, hang out with wife, code a feature, play card games with kids, code a feature, milk the goats, code a feature, puts kids to bed, code a feature, play a video game, code a feature, watch netflix, go to bed.

(Replace any of those “code a feature” moments with “have a meeting”, “run a data import”, “solve problems”…. the point is to make the work progress.)

 

With that kind of continual coding spread across my days, I never really shut down the brain… I ramp up faster each day, I can spread code over a few projects, think more between coding, and just do it all faster.

So why not do this all the time?

  1. It only works when my life is not very busy. Personal projects and time are diminished.
  2. I have to want to be productive. This requires having projects that are enjoying and satisfying, having confidence in the products and the company, and being in a good place mentally and emotionally. It is actually surprising how often one or more of those things is not true, and when one is not true, it tends to take down the others.
  3. Burn out will occur. I can do this for a few weeks, but not a few months.  But at this very moment, we have an event coming up in just over a month – it gives me a nice vision of exactly how long I should ramp up my efforts, and I get a break from it all in early September. (Conferences are work, but different work.)