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 🙂



Hello dear reader. This is my last blog for my Software Construction and Design and as a very important part of development I choose to talk in this blog post for REST API.

REST API stands for Representational State Transferee and provides a lighter weight compared to SOAP. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations, additional information needs to be provided. Most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP verbs (GET, POST, PUT, and DELETE) to perform tasks.
REST-based Web services output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can keep the output you need in a form that’s easy to understand and use within the language you are using for your application. The information you receive when using REST is a JSON formatted document containing the information you asked for. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.
In most of the part REST is easier and more flexible to use. To use REST you do not need to purchase any tools, Postman or Insomnia can be downloaded for free. REST though, is efficient as it uses the small message formats and it has a fast process.
There are some very strong reasons that you should be using REST. First, REST is the most popular choice of programmers to build APIs.  Also REST API is great on making the data available as a resource as opposed to service.
To create a REST API, the following six architectural constraints are needed: 1. Uniform interface, which means that the same resource should not have more than one URL; 2. Client-server separating, which means that the client and the server should act independently. 3. Statelessness, which means that there should never be any server-side sessions; 4. Cacheable resources, means that the server responses should contain information even though the data sent might or not be cacheable; 5.Layered system, which means there might be different layers of servers between the client and the server that returns the purpose; 6. Code on demands, which means that the response can contain code that the user can execute.

If I also refer to the previous blog about SOAP API I would say that there are clearly good reasons why REST API is a better choice to use when requesting/ expecting data and when you want to build your own program. However the decision is yours. I hope I have helped your CS journey. Till next time…



Hello dear reader. After explaining what API is, now I would like to talk about Architectural Styles for API. One of these styles is called SOAP.

SOAP stands for Simple Object Access Protocol. SOAP is a standard based Web services access protocol that enjoys the benefits of long-term use. SOAP is developed by Microsoft.
SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet. These technologies are bad and fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-ReliableMessaging, WS-Policy, WS-AtomicTransaction, WS-Federation, WS-Coordination, WS-Security, and WS-RemotePortlets. In SOAP you can only choose to use the pieces you need for a particular task.As we know, in some programming languages, you need to build requests manually, which becomes problematic because SOAP is intolerant of errors. However, SOAP provides shortcuts to help in this issue. The difficulty of using SOAP depends on the language you use.
One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports.
As SOAP is an ordinary XML file that consists of the following parts: 1. Envelope, which is the starting and the ending tags; 2. Header, which it allows you to extend the SOAP message in a modular way; 3. Body, which contains XML data that the server send to the receiver; 4. Fault, which carries the information about errors occurring during the process of sending the message.

SOAP is mostly used for enterprise-lever web service because that require high security. Some examples of SOAP that I found online were: financial services, payment gateways, identity management and telecommunication services. Also another feature of SOAP is that the API calls can not be cached. The biggest disadvantage is the poorer performance, more complexity and less flexibility.

I didn’t know SOAP existed until I searched for REST (the next blog). The reason why I choose to write about SOAP is that it is a wide used architectural style for API and it has its own place of use, places or situation where REST can not be used.