DEV Community: J.P. Solano

The Most Important Skill A Software Engineer Can Have

J.P. Solano — Thu, 11 Nov 2021 16:28:37 +0000

Sometimes people believe that Software Engineers are like monks, and they spend their days in silence and coding. Nothing more far from reality. On good days, software engineers will code only 40% of their days, other, maybe 10% or maybe 0%. But, what are they doing the rest of the time?, meditating?, eating food and drinking coffee?, playing Ping-Pong?

No really.

First, let’s remember the main purpose of a software engineer is not coding per se, it is solving problems. To achieve that goal, an effective software engineer will need to interact with diverse members of the team throughout the life cycle of a problem until they find an acceptable solution. Within that cycle, code is a critical part, but it is not the most important. Instead, having a clear understanding of the problem and the most efficient solutions is critical before starting to code. This makes it more likely to end with successful results. Remember, the worst possible scenario for a software engineer is presenting a great piece of code that does not resolve the initial problem.

Here a list of activities software engineers do that are not coding, but can help do solve problems in their organizations:

Writing design docs: These allow software engineers to share a high level overview of the problem and the potential solutions with key stakeholders.
Code reviews: Reviewing somebody else’s code, giving feedback.
Whiteboarding sessions: Talking with peers about potential implementations, systems design, solving scenarios, technologies.
Peer programming sessions: When 2 people work together to crack especially hard problems with a brainstorming approach.
Status meetings: When you have to give status updates of your project to the team.
And many more: Product requirement meeting, Design springs, API design springs, UX design springs, 1:1 with managers or direct reporters, Peer reviews, Self assessment reviews, Respond to emails, Collaboration chats.

We (humans) can solve problems BECAUSE we are great communicators!

So, if for software engineers, all these activities would represent 60% to 80% of a their day, then you will agree on the importance of an effective communication skill. Moreover, and thanks to COVID-19, where are in remote office era, where written communication has taken special relevance. See this interesting twitter thread about the future of the remote office.

Communication is the most important of your skills and will determine in high degree your ability to solve problems and in the long term, it will shape your career success.

Here are some practices that will make you a better communicator, and will help you to solve problems in your organization (specially for engineers):

Be concrete or specific. E.g. : If you are responding to a long email thread and you want to agree or disagree about something, don’t assume everybody has the same information that you have:, better rewrite the key points and close with a clear position.
Empathy: Connecting with your audience sounds cliche, but is true. Try to understand who the audience is (1 or many) and, what their expectations are. Using this information to adapt your message will make a big difference in the interaction and collaboration.
Be a good listener: Less is more, and effective communication is not about how long the message is, it’s more about the quality. Try not to be the first in talk; instead listen.
Prefer facts over emotions: Trying to detach from a problem when it is very important for you is hard, but the risk from not doing so is high. If we reduce the discussion to how we feel about the solution vs what is important for solving a problem, we take the risk of leading the conversation to a dead (and very personal) end. People can disagree with your idea. So, be prepared to defend your points, but never take it personally.
Repetition: On any interaction, be sure you have a clear idea what part of your message you want to break through: pick one or two words and repeat it regularly.
Gestures / Voice: Most communication, including zoom meetings, are managed by non-verbal body language and gestures. Be aware of your body language and what sign it may transmit to the receiver. Incorrect body language could trigger unconscious biases in your receiver that will hurt the whole conversation. Using some strategic pauses can increase the value of your ideas.

On better writing skill, I recommend this video about the The Craft of Writing Effectively

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

Engineering is easy, people are hard.
-- Google

initial inspiration from Clement Mihailescu's video about the topic.

Building a React app to solve every Sudoku puzzle.

J.P. Solano — Thu, 22 Oct 2020 01:25:41 +0000

Introduction

Peter Norvig, the legendary Google mogul and AI titan, wrote a python essay to solve every Sudoku puzzle 10 years ago. Back then, he may not have expected that his code will inspire so many other posts and to be ported to so many different languages. For JavaScript, the latest version of the solver that I found was @einaregilsson/sudoku from 2014 .

I thought it would be interesting to create a react app that uses Peter Norvig's solver ideas and adds some learning layers to the UI.

Here are some details from the design document that I used to create the app. Let's start.

If you want to check it out before reading, go to the LIVE DEMO

or the github repo jsolano/react-sudoku-solver

Plan and Scope

Designing and implementing a HTML/JS/CSS Web app using React (with hooks).
Designing and implementing an algorithm that solves Sudoku puzzles in JavaScript. (From easy to extra heavy-hard levels)

Goals and non-goals

Goals:

Build a HTML/JavaScript application that solves a given Sudoku puzzle.
Use React components and React hooks.
Cover aesthetics and usability.
Support entering puzzle strings in the format described in Peter Norvig's article.
Cover Performance of the algorithm (Easy, Medium, Hard, Expert).
Display time taken to solve a puzzle.
Cover Unit testing.

Non-Goals:

UI level automation-tests.
Generate new unsolved puzzle.
Print a Sudoku.
Storage any session data (local or remote).
Accept user solutions to the puzzle.
Make the solver stop in a specific step.

The Initial Design

The idea was to create a sense of flow in the UI, where users can easily understand how to use it.

System Context Diagram

There are two main modules of the app:

First, I made a raw version of the basic JS components and utilities:

Then, I started working on the solver service using JEST for testing.

Later, I implemented the react components for the board, modal, messages and buttons, and then integrated with the solver service using react hooks.

The Learning Layer.

Here's when things started to get interesting. On one side, the UI learning column helped me understand how the solver was working and how to improve the implementation. But, after I ported Peter Norvig's algorithm, which uses a backtracking search strategy and solves ALL SUDOKUS, I realized the learning column was useless because in the search of a solution, it created temp steps that were not valid. I needed to change my approach.

The Turning Point

I could've just removed the learning feature and lived with just a simple solver but instead, I chose to implement other solving strategies that provided the detailed solutions.

I did my research about Sudoku solving strategies, and there were more than 38 options. I was totally hooked. See more here

But all of these strategies come with a caveat: you can work on many lines of code while trying to implement some of these strategies and still not solve all the puzzles. (I learned this the hard way). So, I found a solution:

Creating a react app that uses human solving strategies (for learning purposes and for fun), and only applying Backtracking Search as the last resort.

So now, the app will apply this strategies :

Hidden Singles
Naked Pairs/Triples
Pointing Pairs
And as a last option: Backtracking Search

Also, it comes with a prevention for infinity loops and a spinner while it's solving the puzzle.

Update #1:

Added Pick Just One link to load a random puzzle. (Thanks Andre for the suggestion!)

Update #2:

Added a message when the entered board is solve in the parsing moment. (Thanks Andre for the hint!) This could happens after filtering for cell possible values and all cell get solved. (not common, but possible e.g.: ..6.....2.81.4293.25...34..4.8.1..76..2...8..17..6.3.9..35...94.9732.51.5.....7.. )

Update #3:

Added responsive layout for mobile

Update #4:

Changed the useState hook for useReducer to decouple the state management from the component and also added localStorage persistence.

If you are a Sudoku fan and want to collaborate, take a look of the github repo. Join me in implementing the other 34 strategies!

/JP

The enemies of people who work with ideas are not the people with the opposing ideas. They're those who want to ban the discussion altogether. -Paul Graham