Showing posts with label engineer. Show all posts
Showing posts with label engineer. Show all posts

Thursday, 9 August 2018

SarioDev: Engineering IRL Podcast | Rev.20 - Networking in Engineering



[TECH] SarioDev: Engineering IRL | Rev.20 - Rev.20 - Networking in Engineering
SFW
In this episode of the Engineering Podcast I go through how computer networking works in as simple way as possible. Weow. After you will learn how to apply this information to real life!Improve your people networking skills as an Engineer by learning from the greatest man made network in the history of mankind. The internet.

The Engineering IRL podcast is about improving your engineering mindset and applying these concepts to real life.

Monday, 6 August 2018

SarioDev: Engineering IRL Podcast | Rev.19 - Motivation when working mundane Engineering tasks


[TECH] SarioDev: Engineering IRL | Rev.19 - Motivation when working mundane Engineering tasks
SFW
In this revision of the Engineering Podcast, we answer how to find motivation when working on a mundane task. We all face these kinds of tasks and starting out it may be difficult when it feels like that's all the type of work you get is. Learn how to handle this!
If you enjoy Engineering IRL don't forget to subscribe and share it with your friends. If you want any topics covered just reach out.

The Engineering IRL podcast is about improving your engineering mindset and applying these concepts to real life.

Sunday, 5 August 2018

Engineering IRL Podcast starts Youtube Channel

If you've been following the podcast or this blog you know that the main focus has been the Engineering IRL podcast!

Today I'm announcing the Youtube Channel and we will be uploading all video content for the Engineering IRL podcast there.

Please subscribe and check out the channel!


EPISODE 1 snippet just dropped!

https://www.youtube.com/watch?v=MatLH9UXHuU


Thursday, 26 July 2018

SarioDev: Engineering IRL | Rev.1 - Engineering Rep and how to Improve



[TECH] SarioDev: Engineering IRL | Rev.1 - Engineering Rep and how to Improve
NSFW (Possible cursing)
This is the very first installment of Engineering IRL. A great taste into what this podcast is all about.

The Engineering IRL podcast is about improving your engineering mindset and applying these concepts to real life.
Twitter // Facebook // Instagram

SHOW NOTES:
How to convince a senior engineer on doing things a different way.
Understand to break the rules of a game you must understand it first.
By doing things this way - you can solidify yourself as the "go to" Engineer
What it takes to make change.

SarioDev: Engineering IRL | Rev.17 - IT versus OT and Cybersecurity


[TECH] SarioDev: Engineering IRL | Rev.17 - IT versus OT and cybersecurity
NSFW (Possible cursing)
In this revision of the Engineering Podcast we discuss the differences between IT and OT, explain the key concept of what each are, what the difference is and relevance to cybersecurity. A really simple analogy makes it crystal clear and more! 
If you enjoy Engineering IRL don't forget to subscribe and share it with your friends. If you want any topics covered just reach ou
t.

The Engineering IRL podcast is about improving your engineering mindset and applying these concepts to real life.

Tuesday, 24 July 2018

SarioDev: Engineering IRL | Rev.16 - 1 Drawing can Solve 1000 Problems


[TECH] SarioDev: Engineering IRL | Rev.16 - 1 Drawing can Solve 1000 Problems
NSFW (Possible cursing)
In this revision of the Engineering Podcast we uncover ways you can solve problems via drawings. Technical diagrams usually describe a product or solution, but they can also describe a concept or a process, from which you can draw conclusions or measure against. Also a fun thought experiment!
The Engineering IRL podcast is about improving your engineering mindset and applying these concepts to real life.

Sunday, 8 July 2018

Engineering Podcast Spotify




Exciting news today for the Engineering IRL podcast...

WE'RE ON SPOTIFY

Spotify recently added some more podcasts to be allowed for upload to its platform. As a result the SarioDev: Engineering IRL podcast has finally been accepted!

My goal is that when you search for Engineering in the Spotify app you can find the Engineering IRL show under podcasts within the top 5 results! (The goal)

So if you have any interest in the show or my content, please head over to Spotify and Follow the podcast!


As always, good luck with all your side projects!


Thursday, 5 July 2018

Engineering Podcast - Engineering IRL



I wanted to create a podcast about engineering to open conversations focused on the details of engineering. The day to day work an engineer would go through and then relating those skills to real life.

Taking this concept, this is how the name of the show came to be. Engineering IRL is the name of the podcast and is a shoutout to the everyday stuff, not just the high level marketing things, and show its more than the "boring math" that the other half of the perception is.


I found engineering podcasts on Spotify and many recommendations for all kinds of different ones, but the conversation wasn't quite what I was looking for. This is the gap that I could fill. Think of it as a podcast engineering school except you get some raw mindsets and information that hasn't filtered or edited yet.



Why do people listen?
People listen to the podcast for real tangible advice that they can use to improve as an Engineer. Value is provided through some insight into what Lead Engineers look for and lessons learned. The talks in the car feels like you are just having a conversation about the topic without feeling like a lecture. 

Engineering is the world of professional problem solving and maybe some of the things you learn in this podcast can apply to all kinds of problems you may be trying to solve in real life. I hope one day to show people that the things in day to day engineering are awesome as well.

The podcast is on many major platforms and a list can be found here:




If you get the chance please drop some feedback. The goal is to become one of the top engineering podcasts!

As always, good luck with all your side projects!

Thursday, 21 June 2018

The 10 steps of problem solving like a pro. The beauty in professional problem solving.

Yes. 
I'm talking about being an Engineer.

There are 2 main trains of thought with Engineering work for non-engineers and that's trying to change the world with leading edge tech and innovations, or plain old boring math nerd type things.

Whilst, somewhat the case what this means is most content I read around Tech and Engineering are either super technical and (excruciatingly) detailed. OR really riff raff at the high level revelling at the possibilities of changing the world as we know it.

And so what we end up with is a base (engineer only details) and the topping (media innovation coverage) but what about the meat? The contents?

There's a lot of beauty and interesting things there too. And what's the centrepiece? The common ground between all engineers? Problem solving.

The number one thing an Engineer does is problem solving. Now you may say, "hey, that's the same as my profession" - well this would be true for virtually every single profession on earth. This is not saying there isn't problem solving required in other professions.

Some problems require very basic problem solving techniques such is used in every day life, but sometimes problems get more complicated, maybe they involve other parties, maybe its a specific quirk of the system in a specific scenario.

One thing you learn in engineering is that not all problems are equal. These are

 The stages of problem solving like a pro:


  1. Is the problem identified (no, really, are you actually asking the right question?)
  2. Have you applied related troubleshooting step to above problem?
  3. Have you applied basic troubleshooting steps (i.e. check if its plugged in, turned it on and off again, checked your basics)
  4. Tried step 2 again? (Desperation seeps in, but check your bases)
  5. Asked a colleague or someone else that may have dealt with your problem? (50/50 at this point)
  6. Asked DR. Google (This is still ok)
  7. Deployed RTFM protocol (Read the F***ing Manual - Engineers are notorious for not doing this)
  8. Repeated tests, changing slight things, checking relation to time, or number of people, or location or environment (we are getting DEEP now)
  9. Pray
  10. Go to the bottom level, in networking this is packet sniffers to inspect packets, in systems this is taking systems apart and testing in isolation, in software this is checking if 1 equals 1, you are trying to prove basic human facts that everyone knows. If 1 is not equal to 1, you're in deep trouble.
At this point you are at rebuild from scratch, re install, start again as your answer (extremely expensive, very rare)

And there you have it! Those are your levels of problem solving. As you go through each step, the more expensive the problem is. --BUT WAIT. 

I picked something up along the way and this is where I typically thrive. Somewhere between problem solving step 8 and 10. 

The secret step

My recommendation at this point is to try tests that are seemingly unrelated to anything to do with the problem at all.
Pull a random cable, test with a random system off/on, try it at a specific time of the day, try it specifically after restarting or replugging something in. Now, not completely random but within some sort of scope.

These test are the ones that when someone is having a problem when you suggest they say "that shouldn't fix the problem, that shouldn't be related" and they are absolutely correct.
But here's the thing -- at this stage they have already tried everything that SHOULD fix the problem. Now it's time for the hail mary's, the long shots, the clutching at straws. This method works wonders for many reasons.

1. You really are trying to try "anything" at this point. 2. Most of the time we may think we have problem solving step number 1 covered, but we really don't. 3. Triggering correlations.

This is important.

Triggering correlations

In a later post I will cover correlation vs causation, but for now understand that sometimes all you want to do is throw in new inputs to the system or problem you are solving in order to get clues or re identify problems or give new ways to approach earlier problem solving steps.

There you have it. Problem solve like a ninja. Approach that extremely experienced and smart person what their problem and as they describe all the things they've tried, throw in a random thing they haven't tried. And when they say, well that shouldn't fix it, you ask them, well if you've exhausted everything that should have worked, this is the time to try things that shouldn't.

Either they will think of more tests they haven't considered so as to avoid doing your preposterous idea OR they try it and get a new clue to their problem. Heck, at worst they confirm that they do know SOMETHING about the system.

Go out and problem solve !

As always, thanks for reading and good luck with all of your side hustles.




Tuesday, 5 June 2018

How to get your subconscious to target a specific creative design problem for you

opera house vivid sydney 2018
Inspiration can come from the strangest of places.

Sometimes you think you know how you want your new app to look. But in reality you have more of a feeling that you want to get when you see the look of your new app. I know this because I thought I knew exactly how my app will look and when actually putting pen to paper (figuratively) I know it looks nowhere near anything work showing to anyone.

Okay, typically when you are getting to the point of showing your work, it is easy to be critical on yourself, but in this case, it was more the fact that it is early stage and all I really have is the feeling I want, and not the look itself.

So where do you go to find the look?

Well, firstly I go inwards, think of actually using your app, think of what would be the pieces of information you would want to see, think of what draws you in. Next its looking at others apps out there, maybe googling an app similar to yours and adding best UI. After some time it is best to go outside, maybe to an event, and just observe the world around you.

So that's exactly what I did. Tonight in Sydney the Vivid light show was on and I thought what better place to "inspirate" than an artistic light show where the city itself is the canvas!

Perfect

It turns out I did actually come away with the initial vision of how to achieve the "feel" of the app I'm going for. But you'll never guess which piece of art got me there.

Was it this nicely lit tree?


Or how about this melancholic sea of floating light bulbs?


Well it ended up being none of the above? My vision for the design came in transit sitting on a train listening to a podcast. It's interesting because much like when you are in the shower and you have those "shower thoughts" a monotonous task can get you into a different mindset, different pathways in your brain link.

But wait. Sometimes these thoughts are unique and different, but quite frankly useless thoughts such as

"When you drink alcohol you are just borrowing happiness from tomorrow"
or "clapping is just hitting yourself because you like something"
and "when you say 'Forward' or 'Back', your lips move in those directions"

Great. But it would be nice if that could apply to something I actually want to achieve. So why on this occasion on the train did the problem I was trying to solve get solved subconsciously?

Maybe it was coincidence, but maybe because my mind had locked in a future task i.e. get inspiration to solve my design problem after this train ride, that in my subconscious that was the "next" task. Then as mundane as a train ride was the subconscious has what is next and in that mind state began to solve.

I know the feel of the individual rounds in the game I want to achieve, the font style of the main message and the behavior as time runs out all appeared to me and I expanded it to the colors and the overall game flow.

By the time I got to the light show and had dinner it was out of mind and I just enjoyed the evening. Before I'd even gone out I had already locked in my idea!

The Solve

So try give this a go. The next time you try go out to get new ideas, don't focus on the problem, just focus on the fact that the next thing you are going to do is get new ideas. Lock it in. Schedule it.

But allow enough time for some monotonous tasks in between whether it be on a train (not actively driving) or perhaps the shower before you leave. The trip cannot be anything you are "organizing" and have stress factors to worry about others getting there on time etc. These things will take all of your attention.

Give it a go and let me know if you managed to trigger one of these mind states but got your subconscious targeted at a creative problem you were actually trying to solve.

As always good luck on your side hustle!

Wednesday, 30 May 2018

How to get past your creativity block and why you should try new tools for your design

Let's explore why the tool has nothing to do with the art, but why the different tools can help you open up your creativity. We can explore other ways to get you out of your rut, no matter what you are designing or trying to be creative about. What tools have you determined will help you solve your problems? Why are you stuck? Lets try beating designer's block.

"A Poor workman blames his tools"


We've all heard the saying to some effect - and it applies to engineers and designers as well, but it's not the whole story. Here's an important part not to get wrong - this doesn't mean that tools have no effect on the overall outcome. This can't be true as there would be no point of their existence at all.

So let me unpack a little bit, tools enable, they are an extension of a user, a great designer can design on a napkin if necessary. So, no, you can't always blame your bad work on bad tools, but there is merit and skill in knowing which tools actually work (not just based on reading the reviews and picking on a 5 star rating!), the most experienced professionals will know which tools would be appropriate for a job personally.

BUT. Let me interject here with a reason why there is value in using other tools, even if you have found "the one" in terms of your perfect tool for the job.

Depending on the tools you decide to work with, you are inherently locked into a certain framework, certain pros and cons that come with said device. You have likely picked the tools based on comfort first, and then perhaps some experience you have around the tool or knowledge about it for the job.
You have then determined that other tools cons are not best for the job.

That.

That is precisely where the value can come from. Here's my situation currently. In a previous post, I talked about using Gravit Designer and how I have determined that was going to be the tool I used for 10Up development.

Sometimes you get stuck

The problem is, I got a little bit stuck when designing the new graphics. Now, I'm not sitting here blatantly blaming my tools and saying the designer tool I've chosen is why I can't create the right graphics for my app. But because of the fact that I was stuck, for me it generally  means time for a change.

From another well known quote "Insanity is doing the same thing over and over again and expecting different result", well in this instance it was time to look for a new angle. And that new angle was going to come in the form of new tools.

Change it up


Think about it. You try to solve the same problem using some different tools and different places and in some cases you can expect different results. This is precisely what I was going to do. Change tools. Not because the first tool was broken, but to create a change of pace, change of angle, different perspective, whatever you want to use to explain it, but the inherent cons in the frameworks forced upon you by specific tools may just be what the doctor ordered.

Typically you hear about getting in a different mindset, going outside, looking at other solutions, mediating, etc. But I thought, no, let's try this.

Design the same problem with different tools


So, I got myself a Wacom Intuous and started playing with Piskell App for creating pixel art and Sketchbook for drawing ideas (Yes a pencil and a napkin can also suffice) and started trying to design for the same problem, starting with completely different tools.

At first I just started creating whatever I could create, but eventually that got some juices flowing onto my original problem. The great thing here is the fact that even if you don't completely solve your issue, if you have gotten past a certain design hurdle - boom - all of a sudden you are back. Reverse engineer that idea and come to the original place of work and execute.

You're simply searching for a trigger and other tools may not be where you really want to develop your idea the forced perspective may be all you need.

And 1 more reason


Changing tools may help you with your creative block but there is one more reason for the technical experts out there and it is tying back to what I said at the beginning of this writing
"the most experienced professionals will know which tools would be appropriate for a job personally"

As a professional you owe it to your self learning to use tools you never have in order gain personal, physical experience with other tools and further yourself as an expert in your craft!

As always, good luck to all on your side hustles. If this helped you or made you think at all, share it with your friends and family! You never know who could need it.


Tuesday, 22 May 2018

Why UX is King. User Experience Matters.

If you are an engineer or developer consider this;

It's always interesting when the battle between function and UI/UX as a priority takes place. On the one hand you have the point of view that "if nothing functions, who cares how good it looks" and on the other you have "sure it functions, but who cares if you can't use the thing and it looks bad".

So how do you choose what is the priority?

Let's consider 10Up


10Up is one of those games where an individual puzzle itself can be entertaining. Depending on its difficulty determines how much mild entertainment one would have in the exercise. So the real game is built upon repetition and solving as many as you can against the clock.

So this has always had several design challenges especially considering both UI and UX. In 10Up 1.0 it was imperative that I had function down and whilst considering some UI, no care was taken into UX. I thought I had this middle ground between getting function and some form of UI/UX. 

Engineers typically prioritize function

Here's where it is a problem for most engineers: It was a math problem, and you have the tools to solve it.

This is where functions matters above all because without function who cares what it looks like. The software is a tool, similarly like a hammer as a tool, you wouldn't care if a hammer looks good or ugly, can it pound these nails? - No one wants an expensive pretty hammer that can't even destroy a paper cup.

Well, here's the thing, this comparison is actually not complete enough to be comparable. The equivalent of having poor UX on a hammer (although not entirely feasible) is knowing you have a hammer but not knowing where the handle is. Or when you grabbed the handle, the head would shrink for some reason and you had to press a secret "smash things" button to make the head expand to the functional mallet you were asking for.

So the current issue with 10Up is the user flow for a human to solve a puzzle was not intuitive. It was hard for me to understand this as I could work it out, all the tools were there AND I added some colours to indicate where to be looking. I just needed to explain it once and the person could play easiliy. So I focused alot of the advertising and marketing on including some game play working through the puzzles to educate.

But here's the punchline:

A User Interface is like a bad joke. If you have to explain it, it's not very good.


Great.

So now we know that User Interface is important because people can't use the tool. We understand that the purpose of a tool, aside from is function, IS to be used.
But here's where we say, "but, I have a deadline of yesterday and I don't even know if the thing works or not! I can't be wasting time on user interfaces!"

How do I get more time to focus on UI?


Well thankfully you read this article. Here's how you "make time" for considering your User Interface. The more you practice it, the better you get. It takes just as much time to make a poor user interface as a good one. Remember -it doesn't have to be amazing and completely polished (much like the functions) but if you consistently consider UI even when building new functions, it becomes second nature, like driving a manual and you won't be discussing this again. 

It's about balance.

I am not suggesting you spend 20 hours on UI/UX and 5 hours on function and after one full day you have something that doesn't function. I'm saying as you build your functions instead of creating that default object, you set a few variables and place some frames around it. You include what you need to and you are fast enough that there is no detriment.

Now if I'm not done convincing you, here's the final kicker. 

At the end of the day the tool you are building should be designed in a way that it could scale if necessary, or bug fixes can be resolved. Half the problems from the client will be caused by UI/UX problems.

By contract a customer or client may say "Function A is a necessary requirement" and you can focus on it being perfect. But at the end of the day the first thing the client wants to see is the interface. And when you've got this scrounged up last minute interface, the work behind already seems like it is rushed as well.

For future you - you will be building functions and bandaid fixes purely because of your poor UI!

So work on your UI/UX skills from the beginning!!

Now for some bonus content have a look below for some exploration of 10Up user interface within the game. A point and drag system to a central point as this will push users to understand that they are combining items one by one. 



Below is some early stages of the character designs I mentioned in my previous blog.

As always,  good luck on your side hustle!

Monday, 23 October 2017

Moar Blogs ! - Engineering Blog?

It's all in the title.

I've been working on a whole bunch of small projects throughout the years, many of which I have shared and had great discussions with people in the past.

Well it turns out that at the end of the day, my favorite topic that's embedded in all my project is Engineering, which turns out to be also what I'm good at.

As I've developed as an Engineer my side projects have been a part of that growth and also been a creative outlet. Daily I teach other up and coming engineers what I know whilst at the same time honing my skills. Thinking back I believe it's starting to get to the point where I want to discuss more with other engineers and also share what knowledge I can as well.

Now I follow many engineers, big engineering projects and listened to a few podcasts and followed some engineering focused Facebook pages, but I still feel there's many gaps.

I believe that engineering is the best job in the world and if this type of discussion interests you, feel free to contact me. I've worked with quite a wide range of engineers and whilst my experience is increasing, I'm still quite connected with engineers who are just starting their studies in the topic and also freshly graduated engineers too.

I'm keen to help solve problems, answer questions and also give some tips that will help you grow as an Engineer.