The long-term development of a career and set of skills is something not often focused on when discussing professional fields, rather the immediate benefits of that career (money, prestige, the conceptual notions of ‘success’) are more often discussed than not. While succeeding and generating an income are both important aspects of a career, the process of acquiring new skills and knowledge over the span of that career is just as important, if not moreso.
In chapter 3 of Apprenticeship Patterns, (link: https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch03.html#the_long_road), Walking the Long Road discusses the idea of focusing on the journey (learning) rather than the destination (money/success). While the authors acknowledge that these things can often come together with the acquisition of knowledge, the main idea is that learning itself should be (or should become) a rewarding process over the course of a career in software development/programming. Rather than focusing on the “goal” when trying to improve, the goal rather should be trying to improve indefinitely.
This idea of constantly learning and focusing on the process of improvement rather than a high-paying position is appealing to me, as it focuses more on the creative and constructive possibilities of programming rather than on simply turning a skill into profit outright. While income is a necessity and a benefit overall, oftentimes many of the best paying jobs seem to be “manager” type positions where you might spend more time delegating tasks to others than working on those things yourself. The benefit of having higher income is unfortunately offset by the downside of being unable to accumulate practical experience in the process.
I would estimate then that the best positions relative to constant improvement would be ones where creative solutions are possible, or maybe even encouraged. Open-ended problems often seem to involve improvisation or learning new skills by necessity, and in many cases software development does seem to involve this kind of thinking. I would imagine that active development jobs are best when operating with these goals of self-development, since they so often involve open-ended problems which require learning new concepts.
While I do think that focusing on knowledge for the sake of it is a good way to approach things in relation to career development, finding a balance of learning and exercising known or learned skills is important as well. This pattern focuses on the long-term journey, but I think the shorter term “refinement” of maybe more familiar ideas is similarly important. A healthy balance between these two areas is likely best in practice.
This week I took a look at the pattern “Reading List”. According to this pattern, you should keep a list of books that you intend to read. By making a list of the books you have read and the are going to read, you give yourself an easy way to reflect on your own patterns of studying. As you read you will probably come across more books in the references or bibliography sections. You can add those books to your list as well. Your reading list should also be somewhere online and publicly available. Others may benefit from it or you may benefit from their suggestions.
Despite always being assigned at least one book for every CS course I have taken, I have never (at least until now) considered really using a book to learn about programming or computer science. It seems like a no-brainer to use the internet for anything computer related. Modern search engines allow you to ask extremely specific questions and get almost exactly what you are looking for. Maybe this is because as a student I always know what I need to learn.
As the author points out, it is hard to know where you need to go next or what you need to learn next. I am a student, so I always have a professor who provides a curriculum to follow and assignments to complete. I always know what I need to learn. This is all going to change now because I am graduating in a few weeks. I will have to take the initiative to set my own course of study if I want to improve as a programmer. Without any direction I should probably turn to books.
It is probably time I start reading more books about software development, especially if that is the field I am going to go into. Reading the “Apprenticeship Patterns” book has made me realize books do have a lot to offer aspiring programmers. They are a good way of forcing material in front of you. Because books are restricted by their physical form, authors have to put a lot of material in the book to make it worthwhile. You don’t have to figure out what to learn next; books are carefully curated sections of study, at least textbooks are. It’s about time I start my own reading list too, starting with all the books I neglected to read in the past few years.
For this week’s blog post, I read the section “Learn How You Fail” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The quote beginning of the section is what stood out to me the most. It says, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.” The section talked about how sooner or later you may face failures but the right thing to do is push forward at the boundaries and learn to overlook the mistakes you have faced. In our field, we face many failures but that is not holding us back to accomplish the goals we have set for ourselves. The author mainly talked about becoming conscious of the things that trip you but allow yourself the choice of working to fix the problems that are cutting the losses.
One of the most important things to do when you face failure is to accept it and investment of time and effort to make a small improvement. Allow yourself some time and the “goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure.” I liked the example the author provided regarding Ade. Ade keeps a set of private wikis listing all his current skill set and limitations, this enables him to pick challenges to push outwards and to stop wasting effort on the wrong things which can lead to failures. This is a great example of something that I need to do for myself. Especially keeping a diary or a blog is helpful as I mentioned in the previous blog post that talked about the “Record What You Learn” apprenticeship pattern. This pattern was very true to me. Leaning from failures is important and you cannot excel at everything but accepting these limitations and learning from the failures or mistakes forces you to acknowledge them and focus on improving them so you do not make the same mistakes again.
This apprenticeship pattern might be one of the most important ones in the book because it is something that can be applied to any aspect of life, especially for software development. You need to practice your craft and work on improving it by practicing it each and every day or at least the times when you can in an environment without interruptions or deadlines to help you focus. Software architects need to make mistakes to learn and they need to practice in order to learn. The mindset for this type of approach is to always be ready to perform and be as prepared as you can. If you don’t take action on what you need to know, then you will just be stagnant and stuck in the same place. The pattern doesn’t only talk about practice to improve, but talks about practicing in the best way. You need to try and practice in the best way possible by getting periodic feedback or getting more analysis on your mistakes. Practice will be come permanent in the wrong if you don’t constantly focus on way to improve the way you practice to learn in a more efficient way. This is why it says to practice in a relaxed environment so when you make mistakes you are comfortable with making mistakes and not burdened by it.
I think the biggest takeaway and thing I would add to this pattern is that the only way to learn is by doing and not focusing immensely on theoretical. Anyone can learn the theoretic aspect of software in a short period of time, but there takes more effort and practice to learn the practical aspect since you learn by doing. If someone were to learn all the rules and basics of a sport, but not practice actually playing the sport, then they will not be good at the sport. This is very similar to developing software, since you need to learn the theoretical aspect, but in order to be good you need to keep on practicing and learning. It is essential to always be prepared and up to date with how to learn and the most efficient way to learn a specific software. Overall, the end goal is improvement and to learn to adapt and adjust as time goes on for the most out of your software journey.
The section “Familiar Tools”, found in chapter six in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on the tools a craftsman uses. Focusing and familiarizing oneself with a particular set of tools will help increase productivity since there won’t be any need to go over the functions or specifics of said tools. This also allows one to more accurately know how long a task will take using these sets of tools. However, overreliance on one set is discouraged as there will likely be other tools that are either better suited to a particular task or are an outright upgrade. There are also situations where one will have to either choose your familiar tools and personal efficiency or less familiar tools and the overall team’s efficiency. Regardless, familiar toolsets will become obsolete and have to be replaced over the course of a software developer’s career.
The concept of having to swap familiar toolsets overtime is something I’m experiencing in real time despite my relatively small experience. For example, the first program that I used to develop and edit code in was BlueJ. It’s a fairly simple IDE that focuses entirely on the Java language and is mainly used for educational purposes. I got comfortable with it pretty quickly but then I had to learn C language which lead me to switch to Code::Blocks if I’m remembering correctly. The IDE I’ve been using for over a year now is IntelliJ which I mainly use to code in Java. I used all these different IDEs over the course of around three to four years and in the case where IntelliJ becomes obsolete or I need to code in a different language, like Python for example, I’d have to change IDEs again. This process is going to repeat again and again for as long as I use IDEs; though it doesn’t mean that I lose out sticking with one IDE for a period of time. Like the book states, I’ll be saving a significant amount of time coding in Java since I’m already familiar with IntelliJ and I’ll also have a frame of reference when estimating how long a task will take to get done.
The learning pattern “Record What You Learn” from the Apprenticeship Patterns book is mostly self-explanatory from the title. The main concern of someone who gains a lot of knowledge quickly, such as a new software developer, or, in my case, a software development student, is retaining that knowledge. The chapter describes some good ways to track this learning, like with a wiki or a blog (hey!). Having to relearn or continuously practice concepts or bits of skill is time consuming and wasteful, especially if you don’t have something to quickly reference. This is a solution to that problem.
Recording and retaining my learning has definitely been a problem in the past, although I’m trying to get better at it. At the start of my sophomore year, I realized I had forgotten a solid chunk of the programming skills that I had learned at the end of my freshman year. I had to work a lot over that summer, so I didn’t have a ton of time to practice these skills through personal projects or places like LeetCode. Getting back into the swing of things, especially as difficulty was ramping up, was a struggle. Luckily, I haven’t hit a patch like that since, but there have been plenty of times that I found smaller, but still useful concepts, escaping me.
Some things in this department might be like remembering some concepts, but forgetting the implementation, or even just one key part of implementation. This is exactly where a wiki/blog would be super useful. I find I usually follow my own train of thought best, as I assume is the same for everyone, so having something to reference in my own writing, in a way that I find is useful in understanding a topic, is best as well. Just in recent memory, I had some trouble trying to remember how to create a custom comparator for two objects. I had just done it last week, at which point I had to look it up. It was excusable the first time, but just a pain the second time. So, even after a week, I still face these troubles. I definitely need to get better as recording my learning, so this learning pattern is a great point of emphasis for me.
I decided to once again choose patterns that cover related issues, this one being about passion. This is something that I find myself struggling with on and off between projects, where I have moments of excitement starting a project and successfully implementing a function, but often encounter issues that can stifle this passion. Beyond this I simply have times where I lose the drive to work on personal projects and struggle to find the desire to continue working with software design of any sort. Thus for this post post I chose to focus on the Nurture Your Passion pattern.
There are a few key points mentioned to help with this issue. The first mentioned is that you might just have to put any current work you are struggling with aside if possible to focus on another aspect that interests you. This can be in the form of a different part of the system you are currently working on or even just a breakable toy that will help you learn and grow, rather than stifling this advancement. Additionally, you should try to find a community that you can participate in. More often than not there are others in similar situations, and if you look online you can find discussion boards or even whole websites that have a variety of programmers discussing with each other. Getting different perspectives on the craft from others can reveal new insights to you, reigniting your interest in what you do. Furthermore there are even online study groups if you need particular help with specific issues. Beyond this you can also try reading some of the classic, well-regarded books in your free time. This will allow you to learn in a very low risk environment, removing the immediate stress of having to have functional code and allowing you to enjoy the intricacies of whatever is discussed in the book. Finally, if you are in a professional setting, you have to set work environment standards ahead of time. This can mean setting a hard time for when you stop working to ensure any toxic conversations are steered towards a productive topic.
While I am not in a professional setting yet, this information has helped me. I have never really thought about having to set standards for myself going into a job and will keep that in mind for the future. Many of these tips, as always, sound like they will be very helpful in the future and i have nothing to disagree with.
Something that I am sure many others who have pursued a career in computer science have encountered is failure. Throughout my attempts at coding, I have found that a vast majority of my time is spent trying to fix my own failed programs. This was, and can still be, a pretty large barrier to my enjoyment of programming, as simply trying to fix your own broken code over and over give the impression that you are not really making progress. To get a different perspective on this issue I chose to cover the Learn How You Fail pattern for this week.
This pattern gives a few key ideas to keep in mind when you feel like you find yourself stuck in a rut of failure. Firstly you should try not to focus on the disappointment of your failure, but focus on determining what happened that caused this failure. Work back through what you did to get to the point of failure and determine exactly what you did that caused this, then make note of the cause. If you can record these issues you will be able to determine your own strengths and weaknesses. This may lead you to realize that you have to put in a large amount of effort for seemingly small gains, but this will allow you to set accordingly realistic limitations on your goals. Accepting these limitations is also important, as it allows you to determine where you should and should not spend your time, which may require you to drop some projects for now. This will allow you to focus on any other issues you are encountering, and you can always return to the previous issue later.
So far I have found that failure is something that goes hand-in-hand with software design, especially when learning something new. Personally, I have always taken the very straightforward hit your head against the brick wall until it breaks method with failure, often spending a long time solving small issues. After reading this pattern I have realized I should be recording what I am doing wrong each time, and that would certainly save me some time in the long run. Though I am still early in my career I found this pattern to be useful yet again and had nothing to disagree with.
When working on an open-source project, please get in the habit of downloading the latest version of the code (preferably from their source control system), so you can review its history and track future developments. Please take a look at the codebase structure and think about why it is organized the way it is. Look at how developers manage their code modules to see if it makes sense and compare them to how they might have used them. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. It will give you a better understanding of the projects; Also, make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with it. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider whether this is a legacy design that needs to be refactored; consider whether making a toy implementation for the relevant feature would help clarify the issue.
You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve minor problems more quickly and quickly. You’ll be able to tackle issues that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the Git distributed source control system written by Linus Torvalds or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally use data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.
In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something significant. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [
Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the project’s construction and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same concept can be applied?
This week I wanted to look more into MongoDB. I found an introduction video titled “MongoDB in 5 Minutes with Eliot Horowitz” from MongoDB’s YouTube channel to do so. I wanted to learn more about MongoDB because we have been using it a lot in class, but I do not yet have a clear idea of what it is and how it works. I have already taken a relational database course, so I have a clear mental image of what an SQL database is and how it is organized. I know MongoDB is not a relational database but that is the extent of my knowledge.
They start by describing relational databases as excel sheets on steroids, which is a pretty close comparison. They then use an example of a patient record keeping system for a doctor’s office. A patient information table might need multiple phone numbers and addresses, and these columns would end up being mostly empty in a relational database. We might also have the patient’s information spread over many tables, adding complexity. When this database is used in in application it makes the application inefficient and hard to maintain.
MongoDB uses documents and each document can be different. Not all the documents in this case would have to have the same number of phone numbers or addresses. They don’t need the same number of columns like records in a relational database table.
This video is very short and was also created by MongoDB. It is not surprising that they only show one use case where MongoDB is better than relational databases. If relational databases are Excel then MongoDB is kind of like Microsoft Word. It is important to remember that relational databases enforce things like integrity that MongoDB doesn’t, making it better in certain situations. Using multiple tables also isn’t too much of a problem; that is what joins are for. I can definitely see the advantages of using MongoDB now though. The idea of documents is so simple and it is easy to grasp compared to relational databases. This provides a good start to look more into MongoDB. I may have needed this knowledge for the final project, though we won’t have one anymore. I will definitely be using MongoDB in the future though as it is just becoming more and more popular.