Expose Your Ignorance

Hello my readers and welcome back to my blog. Today I am going to write about another Apprenticeship Pattern called Expose Your Ignorance. I totally agree that it might sounds weird when you hear it but you will change your mind by the end of this blog post.

You have just started working for a company, its your first job and everyone expects a lot from you. You are now a Software Developer and its time to show your skills. Too much pressure I know!!

This chapter of the book talks about how you should not hide what you don’t know as that will make you more ignorant. Everyday of the job and everyday of our life is a learning process for everyone and you don’t make an exception. The authors strongly encourage every software developer out there (especially the inexperienced ones) to expose their ignorance by asking questions. By asking questions you are letting your team know that you want to learn and lower the level of ignorance.

Pride! Ahh pride, this is what holds most of the people back. I totally get it that it’s easier said than done, but you should really leave your pride aside when learning. Yes its true, you can go and do your own research about the matter but that it going to take you a bigger amount of time compared to the situation where you can just ask your teammate or your manager.

If my close friends were to read this blog post would say: “Look who’s talking!”. Yep I got the same issue, I am very afraid to the idea that my teammates will think how inexperienced or ignorant I am so I just keep going on my own and stress myself until I find the answers of my questions. However I have realized that working in a team with a great environment makes it way easier to address to your teammates or manager for questions you might have.

So yeah..long story short: Ask questions about what you don’t know or need to know! But keep in mind to try to shorten the list of the things you don’t know soon. There will be times where the list will get longer than usual and sometimes shorter but as you choose the shortest path to expose your ignorance, you will notice that by the end on the trip you will be an expert. Don’t get discouraged, ASK!

AMPATH-WSU Sprint 1 Retrospective

Hello my readers. So as I mentioned in the very first blog for this semester, all the blog posts will be related to that class. This is a Capstone class and we are working in groups in a project that I am really looking forward to give my contribution.

But what is AMPATH? AMPATH stands for Academic Model Providing Access to Healthcare and is a healthcare partnership based in Kenya and created from different organizations. As far as I understood from my professor, there are multiple universities working on the AMPATH project. What we will be doing this semester is to help developers in Kenya as they are rebuilding the system. Excitingggg!!

Before the second sprint kicks in, here I am thinking about how did this last sprint go. Overall good I would say! My biggest disadvantage was that I had to be away for a week from the country and I kinda missed a few meetings but was able to recover in time without missing much information.

Starting working with AMPATH felt to me just like starting a new job. During sprint one we mostly got familiar with tools, the program we were going to use, our teammates, the systems we were going to use. We were assigned to different teams based on our availability. Fortunately I knew half of my team as I had worked with them in the past in other projects and was looking forward to work with the other developers as well.

In all this new process, I would like to point out one of the systems that i really liked and had not used before: Trello. It was very convenient to have all the stages of the First Sprint lined up in front of you (Product Backlog, Sprint Backlog, In Progress an Done). We started to organize our work and what needed to be done to increase our productivity.

Another step we took was pulling, cloning and getting familiar with the code of the project we were going to use. As a new MAC users (pointing this as I don’t know Mac too much) I had a few issues with running the code in my computer. Kristi though, was able to help me figure out the issue and solve it. .

Unfortunately our semester is a bit short for us to have big development getting done. However I am very excited for the new learning that I am and will be getting out of this project. I choose this project because I thought this way I could assist in an application that was real and had a good purpose.

I would consider this sprint as a research sprint where we researched and tried to learn ans study a lot about Karma ( a test runner for JavaScript), and JavaScript itself. Personally I hadn’t worked with it a lot and needed a few more blogs/chapters to read about it. I am really looking forward to the next sprints and to see what we will be achieving. I didn’t lie when I said it felt like starting a new job :).

 

Who Doesn’t Hate Their Computer?!

Hi dear readers. Welcome to my next blog post. In this blog post I am going to write about an article that I read with title “Why Doctors Hate Their Computers” written by Atul Gawande.

Gawande starts the article writing about this new system that the hospital he was working was upgrading to. The new system’s name was Epic. Epic is a leading provider company of software for healthcare industry. Gawande shortly explains all the process of training and using this new software, as well as the consequences that it brought with it.

I found the article pretty interesting as it is always good to know, especially as a developer on where do the other industries stand with technology and how are they liking it. I am personally in a Fleet/GPS industry and an internal developer. In my opinion doesn’t really matter which industry you love or hate, technology lies in the same path (most of the time).

Just like Gawande, also a lot other healthcare doctors/employees were not happy enough or at all with the new system upgrade. It is unfortunate how in some things this system had a bad effect when it was supposed to improve all the process. But while reading the story I find so many truths in this article that even I, a software developer can relate to my place of work. To be honest I would say you are ling if you come up to me and say that the system your work/school is using is amazing and you got no issues with it. It is not that the technology is not perfect but it’s people behind those written lines of code. People well trained or not, people with good knowledge or not, people with good skills or not. Having these people combined leads to problems with software.

I would like to point out one part of the article when Gawande’s collage Dr. Sadoughi was explaining how she felt about the new software and how slow it made her work. In a moment she mentions how she logging was very bad as all other doctors could access the documents of a patients, which in my opinion is amazing as, myself as a patient have to explain to each doctor over and over again on what my current health condition is. As far as the other doctors not putting the exact notes for patients, I would say that is a professional matter. At this point the doctor is not playing by the rules but slacking by just using enough words for the billing system to care but not to help in the overall functionality process of this software. In the same time this doctor is hurting the patient as well as the other doctor has no clue of the real health problem the patient has. Let’s be fair at this point!

I have experienced a lot of issues with systems at work too. Once my boss said: “Think how good a software is, if even a developer is confused”. Its true that systems have problems and maybe this particular system had more issues but technology is the future and it has improved our lifestyle in so many ways and we can’t deny that. When creating a system the PMs should always consider the most important factors but also work with a group of users from different departments who represent the interest of them all .

I strongly believe that systems and technology can be improved even more if the correct specifications are set and met, but just like other things in this world, nothing is perfect. Technology doesn’t make an exception.

Unleash Your Enthusiasm

Hello dear readers. Welcome back to my next blog post. This time will be talking about enthusiasm in your new/current work place.

This chapter of the book  talks about how to feel and what to do about your enthusiasm at your work place, being that a new or current environment. I believe these advises would mostly apply to a new work environment as in an old environment you already know your coworkers and your boss. The author gives credits to people with enthusiasm and strongly supports them to unleash and keep the spirit up.

Getting into a new work environment it is indeed a bit hard, especially when that is your first job. When it comes to choosing a job, unfortunately you can’t really know what kind of team and people you are going to work on unless you have been recommended for that job. So being nervous is FINE. And I was crazy nervous in my interview and first week of my job.

I have heard a lot of stories about teams with employees who don’t accept suggestions or new ideas and especially when those are coming from a new employee and a recent graduated student. If you were to read their face, it would say only one thing: YOU DON’T KNOW. At that point it is time to move up and get to your manager and if you are still not heard I truly think is time to move on. But always keep your spirit and enthusiasm up because just because those people don’t accept new ideas doesn’t mean you are wrong.

Never hold back on ideas and always express them. A good team will listen to your idea and will take it in consideration and will explain why that might or not be a good idea. Nobody was experienced on their first jobs! Its true that these new team you are in might know more than you but you might know something they don’t and that’s a plus to the team productivity.

Keep in mind that nobody knows everything. Try to find the person who you think would listen and welcome your ideas. Also accept critics, its very important for your development.

 

Reading List

Hi dear readers. Welcome back/all to my next blog post about the next Pattern. The next Pattern I am going to write today is about ‘Reading List’. Yep you heard it right! Reading List! Just because you are a developer doesn’t mean that you got no more reading to do.

This Pattern in the book talks about how to start with a reading list and how to keep up with it. The authors make very good points when they say that its hard to even start a reading list as you might not be sure what to read first. I like how one of the recommendations is to ask your mentor/professor. They would be the people who know your development level better than anyone and will definitely be a great help. Another point to keep in mind is that the initial Reading List you have created might (probably will) change after you have finished one of them. Having a Reading List is great because it also makes you reflect about what you read previously.

As mentioned in the book, we should always think and analyze about the book we just read and try to figure out on our own on what should be the next book to read. Computer Science is one of these field that new things will  always keep coming up and what better than books will be describing these new innovations. Indeed these new books should be on top of the list.

I believe that there will be cases where you/me as a reader will be disappointed on one or more books. It’s not right that just because one book was not good enough, we should stop reading other books. I think that when you don’t find a book interesting or good enough, it’s a good sign as you are thinking about the book content. This will give you a better understanding on what you would like to read next and what is your favorite area. For example, for my reading lots of books about programming languages wouldn’t be too much interesting. On the other hand there are people who love reading each and every book about programming languages and this is because they’re passionate about it.

I would recommend to just start somewhere, and then you will be able to figure out on what to jump on next.

Familiar Tools

Hi dear readers and welcome back to my blog. Today I am going to talk about another Pattern that I read from the book Apprenticeship Patterns. This blog post will be about familiar tools.

Once we start working or coding on our own we start to like and choose which tools we like and which ones we do not. It is just a matter of time for us to figure it out. Once we do though, its hard to switch. When I started coding, I was only learning tools that were recommended from our professors in school and as I was ‘scared’ to experiment I always choose not to switch even if I didn’t like it. Going to work and school at the same time was amazing as I was facing new tools in both environments and I was able to tell which ones I liked and found more useful and made me more productive. And as the book says, once you find your favorite tools, its hard to switch!!

This chapter talked about how all of us have our own favorite tools and we find it hard to switch even if the productivity sake is in risk. It would be our decision on weather to give up our tools or not but we have to face consequences. At the same time, just because a tool is great for you don’t mean it will  be great for someone else. Something that you might find easy, might be hard for someone else.

There is one example I would like to give for this Pattern. I started to use Eclipse on my second semester of Computer Science and I wasn’t crazy about it, but as we had just transited from BlueJ was very cool. Two semester later is when I started my job and over there the developers were using more advances IDEs and I was very excited to learn and get familiar. Eclipse went out of my list right when I learned about Illuminated Clouds. Very ‘smart’ IDE! However, Eclipse was still the only option in school and I was hating it and started to recommend to other people. Some of my friends found it very useful to use and some others already loved Eclipse for what it was.

Last but not least, I really liked the recommendation from the book that was suggesting to have developers create a list for all familiar tools and keep researching is the list was smaller than 5. All of us will probably change lots of jobs and lots of companies will have their tools, but its always good to have your own area of expertise.

Hope you guys found this blog useful…Stay tuned for the next Pattern from this cool book!

Your First Language

Hi dear readers. Welcome back to my blog. From now on I will be writing for different Apprenticeship Patterns that I will find interesting in the book to share with you.

I started computer science with 0 knowledge in coding, programming languages or anything else related to this world that I find beautiful nowadays. My very first programming language was the famous Java and not because it was my choice but because my first contact with coding was in Intro to Programming (CS-140) and the teacher had chosen Java as a language. Now that I think back three years ago, I am happy that I started my software craftsmanship with Java.

A summary of ‘Your First Language’ Apprenticeship Pattern would be that if you start your journey different from me (in the meaning that you can choose your first language), the book recommends you to research about it and try to figure out what is the most suitable language from you. It doesn’t have to be one of the most popular language but as every language has its own characteristics you got to pick the one you find more easy (or hard, if you like to challenge yourself). If you don’t trust your research skills than you can ask your friends who are familiar with programming languages and they will  be able to tell you the differences between a few languages and why they like what they like. Learning the language is not the only step of the process as you will be using this language forever to solve different problems you might come across. Remember, switching is always an option..

Most of my friends had started programming with Python which I have heard is a very easy language to learn and use. I remember when I started to learn Java I used to try and solve other problems (as much as I could) so I would get practice and in my first problems I was not using any other libraries. Practice is the key, believe me! A language is easy to learn but it has a lot of volume. Once my boss said: “Its not the language we should memorize, its the data structure” and I totally agree as in your journey you will work in different companies that will use different languages.

I really like that this is the first pattern included in the book as the first language is the first contact you have with coding. And don’t forget..Practice 🙂