--Originally published at Debugging My Mind

Today I’m gonna talk about two TED talks I watched, one done by Sam Richards, speaking about empathy, while the second one was done by David Marquet, focused on leadership.

We always think of empathy as the stereotipic small definition of “putting yourself in someone else’s shoes”, which is not saying that is wrong, but rather how deeply we actually think of it. As a student, I’ve been able to travel to different countries a few times, the most special one being the time I lived in Japan for a summer, living with a japanese family, studying the language, experiencing their culture and meeting people from a lot of different countries. An experience like this is, I believe, one of the biggest “eye openers” that a person can have towards the world, how the moral rules, the stereotypes, your opinion on plenty of things change, when you truly notice how small of a world you were originally living in.

I can safely say that experience has made me a very open-minded person, and it only goes better from that, you learn to understand, you start asking yourself “why reject things without a reason”, or “what’s truly wrong about something”, there’s plenty of moral rules here in Mexico that we all follow or consider normal without ever asking ourselves why, or even doubting lots of them at all, it can lead to people hating, judging, going out of their way to make their voice be heard when they complain about someone when it’s doing absolutely no harm to them, just because it doesn’t fit in the “normal” scenario that they’ve lived in for so long and that they don’t want to have broken.

That’s the thing with empathy, just like the talk says at the very end and that I liked

--Originally published at Debugging My Mind

I like correlating what I read with my own developping experiences, trying to notice what I’ve been lacking, what I’ve been doing and how it can be similar to what the book refers to and finally, what I’ve been doing wrong. The last one tends to come up a lot in the scholar environment, as a lot of times we strive to get things done in a certain way or period of time and with a different incentive compared to a job (having the reward only be grades and learning instead of monetary compensation) which lead us to a lot of mistakes and  complications.

When it comes to a quality assurance plan, we most definitely aren’t used to make one, we usually only do proper testing once things start breaking or when the functionality is “completed”, leading into a bunch of work fixing and dealing with lots of bugs.

A really detailed plan seems very necessary for big projects, ones that will be on development for a long time and require the utmost efficiency to be on proper schedule and budget, but I don’t think this will be the case for all projects, it feels like the book, while mentioning a lot of the tools for developping these plans (like taking in consideration defect tracking, unit testing, source-code tracing, technical reviews, etc.) it doesn’t mean we have to apply every single one of them, meticulously in every project we work on, I believe the goal is to learn to sit down, analyze the problem we’re solving and what we’re developping and choose a good schedule of how quality will be checked and assured throughout the process, which in essence, becomes a plan, a quicker one it may be, but a plan in the end.

As we go into projects

--Originally published at Debugging My Mind

Yes, just when we thought just planning was good enough we have to tackle this new idea, preliminary planning, but is it really new?

There’s a lot of activities and processes when working that we do without much thought, that pass on as quick non important topic, but after some reading and a bit of reflection, it becomes clear that they are actually  way more relevant than they seem.

How many times do we start a project based on an idea, just to realize not everyone is actually fully attuned to it, I certainly have, a lot of the times we assume that everyone understands what we’re going to do, but it ends up causing some confussion and problems down the road, it even prevents potential improvements to the project due to not fully understanding the goal. We all find it silly to have to physically write the actual objective and vision of a project, but it ends up being more useful to understanding what we’re all going to work towards in the end.

In school work, we often don’t truly have an external group making the huge decisions for our projects, it’s mostly up to us (with a bit of feedback from teachers most of the times) to decide and do changes as we see fit or simply choose the features we need to include in our project. This ends up being messy most of the times, overestimating what we can add and leaving things out that we couldn’t complete or even changing our end goal depending on the final product we were able to create.

There’s definitely little to no preliminary planning in most projects we do for school, mostly due to time restrictions and the advancing nature of the work, where we’re being guided by our teacher,

--Originally published at Debugging My Mind

Whenever a new project arises, becoming a potential client, software devloppers jump at the opportunity promising and proposing fantastical and optimistic things, it feels like when you’re told “tips” for job interviews, you want to exaggerate and be as optimistic as possible, nothing bad, only good stuff. Thanks to this, everything becomes “possible” and very attractive time estimates are given really fast, even when estimating the time for a project can be incredibly difficult and probably needs time itself.

I think that’s the main problem, nobody wants to say that something is impossible or that it will take really long, everyone wants to “look good” about their proposals so they get the job, but isn’t failing and delivering late, or even failing the project altogether worse?

Some time ago when I began studying software engineering, I had teachers be very persitent with saying “you’re not programmers, you’re engineers”, we are not being taught to be programmers, anybody can do that, and the way software development is handled a lot of the times is from the programmer perspective. “Sure I can do this”, “Yes this can be done in X time”. Being engineer means being able to plan things, to make estimates and evaluate the given problem, use logical and exact knowledge to backup their decisions.

It’s true than in many other work areas, including engineering benefit from just adding more people to projects to make them finish faster, divide all the work load and ta-da~ it works, but this is definitely not the case with software. Why would it sound better to make smaller teams for projects instead of adding more people, simply because in my own experience it takes more effort to coordinate everyone, to have each of the members be in sync with what’s going on and what

--Originally published at Debugging My Mind

I’m gonna take a different approach from now on, instead of mentioning things the book is saying by chapter I’m just gonna give out my opinion on the topics it talked about, whether it’s one chapter or the other will be up for guessing but it’s probably more important to identify the topics themselves and what I think of them.

First off we have staged delivery, dividing the project in different stages which all need to be able to be delivered even as a finished product at different intervals instead of having one big thing that is all delivered at once a single time at the end of a project.

I think this kind of project model fixes not only a lot of the developping issues that exist already, but also a lot of the “business” or non developping issues that stakeholders and users have with development itself.

People want results, they don’t want to be told “oh it’s going good” or “oh it’s X % done” and not actually see the fucntionality or what they’re going to receive yet, sadly, since software development is not a tangible thing except for documentation for a long time before you can see the actual program working (at least most of the cases with the usual developping methods) it’s bound to face a lot of credibility issues from the stakeholders and is one of the main problems we see these days.

For me, staged delivery seems to be a really good alternative to face all these problems I mentioned, being able to deliver something tangible in periodic releases involves the end user a lot more, to be able to meet their expectations and for them to see continous results from the development, which might just be worth all that extra effort that can

--Originally published at Debugging My Mind

Another day, a different book, this time looking at The Mythical Man-Month by Frederick P. Brook. What a weird title might I add, which is also a pattern that comes into the chapter titles, but in the end surprisingly, they provide very interesting analogies.

We start off with one of those, how animals and beasts would struggle on tar pits sinking down no matter how strong or small they were, just like that, programming teams can sink down the tar pit of a projects work, may it be a big or small team, nobody is exent of the dangers that software developping entails for the success of a project.

Thinking of programmers, a lot of people think of the small team in a garage, developping a program, just like anybody can do it, why the need of big corporations with hundreds of developpers and employees. Well yes, anybody can make a program, but it’s the difference between a product, a system and a system product that marks the quality and trascendence of a lot of the results, each as much as 3x harder than the basic one. As a lot people like to see it, everything is nice and pretty until you have to document everything, explain every nook and cranny so anybody can get involved, and even making it work with other programs, this is what sets the difference to have a program become a system product.

So with this comparison of the normal programs and a programming system product, and how a software developping project is compared to a tar pit, why is then that so many people want to get into programming or are so eager to try it out. In my opinion that’s the most interesting thing presented in this chapter, why is programming so likable? even