My name is Lorenzo Pasqualis. I started writing software in 1984. Over the years I used many languages, technologies, and tools. I have been in technical leadership positions since the early 2000s, and in full-time executive roles since the beginning of 2014.
Today I spend most of my time focused on the art of architecting scalable systems, organizing engineering efforts, hiring and training talent, managing people, leading engineering teams, and helping designing solutions in the EdTech industry. I am very close to the technology as an architect, but my principal concern is people. I am an active advocate for Women in Tech, a believer in servant leadership, and a lifetime learner.
I still code; mostly personal projects or to help my teams. Coding is a passion that will never die, and staying close to the technology makes me a better leader of technologists.
I am the author of a blog, CoderHood, dedicated to the human dimension of software engineering. In other words, it's about people and their life in the software industry.
I have been x-posting some of my articles here on dev.to. Dev.to is an amazing community that I like to support in whatever way I can ( Ben and Jess, you rock! Well done! ). If you have any questions that you think I can answer, ask away. I will respond as best as I can, and I might write a blog post to expand on the topic.
Ask me anything!
Top comments (74)
I've gone through the same transition: How have you managed to balance "management" with keeping up with the technical details and implementations that impact your team? It's hard to find time to actually write code these days!
I write very little code, and I decided that it is ok. It is hard to scale otherwise.
Now... it depends on how many people you have. I have 10 direct reports and 35 engineers overall, so time for flow is pretty impossible to find.
I mostly work on personal projects at home and keep up that way. I am also very active as an architect and spend a lot of time brainstorming high-level system designs and data flows. Finally, I try to participate in code reviews to keep up with some of the details.
What is your advice for people in their twenties trying to get into their first programming jobs?
My advice is to use what you have to your advantage and understand the issues that hiring managers might be facing that you can resolve. Here are some ideas:
1) You are young and energetic. Bring your passion for learning and for technology to the table. Present yourself as ready to learn, thirsty for knowledge and ready to grow in your job.
2) When you go for an interview, do your homework. Make sure you know everything you can about the company and the product. Present yourself as very passionate about what the company does.
3) You can't bring experience, but you can bring new ideas. Companies seek young tech talent to eliminate old crusty ideas that seem to be unshakable, and if you present yourself as someone who can bring new ideas with passion, that goes a long way.
4) Seek jobs at your level in companies that have good mentors. If you find a boss who is a great technologist who is willing to grow you, it will be well worth the time and effort even if the initial salary is not great.
5) Try to figure out what you want to do long term and what your goals are. All of that can change anytime, and that's ok. Having plans based on the information you have right now is the important thing. Employers will be impressed by someone with a clear set of goals.
6) Try to stay in any job for at least two years, unless you are absolutely miserable. Jumping from job to job is not a good thing.
7) Don't worry. You can do this.
@Lorenzo, Staying in a company for 2 years where you have no mentor or is not in line with your skills (e.g. hired as a Python programmer only doing Unit Testing or babysitting old code...) is also not an alternative. Staying less than 2 years in a company is not an alarm bell unless you do it multiple times.
Good mentors are key, regardless what you earn in the beginning it can change your career rapidly in a positive sense. I noticed the biggest career-boosts when being mentored during tough times.
Interesting read btw :)
What has changed most in the industry since you started?
What has stayed the same?
Thank you for the question, Ben. This could be a 5000 words response, but I'll try to keep it short.
What changed in the industry.
When I started everything was local on the developer's machine, it was very difficult to get documentation and even things like source control management were very primitive. Debugging was mostly done with "printf", and the concept of "production" didn't really exist. Most serious code was written in C, and scripting languages weren't really a thing (with some exceptions for shell scripts.) Everything was done from scratch. I spent a lot of time writing string manipulation functions in the old days.
Today everything is "online", developers have amazing tools, powerful debuggers, and a huge array of libraries and language choices. Scripting languages changed the game, and web development is a large percentage of what coders do, and a good entry point for many programmers.
In the old days, developers were much more "low level". Memory needed to be managed by hand, and memory leaks or buffer out of bound crashing bugs were a real evil pox. I remember when writing C code how it would regularly reboot my machine when I had buffer overrun bugs. Fun times.
What stayed the same
The fundamentals of programming languages are the same, but these days learning frameworks are almost more important. So, coding itself has not changed very much, but the context around coding has shifted dramatically.
Another thing that hasn't change is the passion of developers and their love for technologies.
Is it that learning frameworks is more important or that there's a tendency for people to put a lot more emphasis on them? Additionally would you say that the ability to learn quickly/read a framework and still understand (without knowing the framework) is more important?
The tendency is for hiring managers to ask if people are familiar with frameworks. Also frameworks tend to be unruly and not always greatly designed, making them a bit challenging.
The ability to learn quickly is more important once you are on the job. Knowing it is more important when you apply for a job. I know... one of the many contradictions of the industry.
I am generalizing here, and giving a view of what I see in the industry. I personally don't really care very much of expertise with frameworks, but I "grew up" as a developer in the 80's and 90's, so my view probably reflects that time.
What are some areas in leadership that you think engineering didn't adequately prepare you for? For me, I'm spending more time in product now and I've started getting better at understanding or formulating the "why" behind what we choose to engineer but still having a hard time with the articulation and organization of strategy for others to see and understand.
The answer is pretty clear in my mind: Soft skills and Project Management Skills.
Engineering didn't teach me much about soft skills and as a leader, I had to develop those from scratch. People are very complex, and leading them is a subtle art of seeding ideas and waiting for them to grow.
Also, project management. The "why" is a super important aspect of project management, but there are others. For example, an understanding of the importance of evaluating cost vs. value of anything that is being done is not something that an engineering background really prepares you for. The economy of software development is a key aspect that is important to understand for proper leadership.
oh yes, couldn't agree more.
Thank you, Jess!!
Hi Lorenzo thank you for sharing. I have little to no background in software. I work in a small firm as their marketing graduate and constantly find myself frustrated as I don't have the skill set to implement my ideas or communicate it with a third party developer (no in-house developer). I want to learn how to communicate with software developers and I am interested in software architecture and scalable systems, considering restudying. Do you have any tips on ways to learn how to communicate with developers to lead projects and build towards becoming a project manager?
Well, my view might surprise you. I think that developers need to be able to communicate with you, not the other way around. It is fundamentally important for anyone who writes code to learn to have discussions with non-technical people.
If you work with third party developers, select one who has at least a sales engineer who can communicate both with customers and with the engineering team writing the code. If you had your team, I'd recommend hiring a good technical leader that can talk to non-technical audiences.
That said, I'll try to answer your question more directly.
When it comes to scalable systems, I think what you want to read up about is SOA. I recommend this book to get an idea of how to think about distributed systems. After that, it is a matter of experimenting with technologies that are more directly involved in whatever projects you have in mind.
To be able to lead projects, you need to be able to gain the respect of the engineers involved. Acquiring enough technical knowledge to be respected for your technical skills by a group of developers is very difficult without a technical background or coding experience. So, you can take that hard and long path, and dedicate a couple of years learning, coding and experimenting. However, it'd be easier to gain their respect with strong leadership and project management skills. If you partner with a good tech lead, you might not need to learn the tech in full-immersion. You could learn it by listening carefully to the discussions the engineers have and asking your technical lead to be a technical mentor.
Project managers don't have to be developers. They can be fairly high-level if you have a strong lead. You might want to study agile development processes such as SCRUM to get a sense of a possible avenue you could use to lead a project. Here is my favorite book on the topic. There is a lot here. Your question could be a great topic for a future blog post that I'll need to write.
Lorenzo, thank you for writing back. It's really encouraging to receive such a thoughtful response. I appreciate how you provide useful resources and direction. I've heard good things about SCRUM, I'll look into it. I agree that getting a mentor and tech lead would be helpful. Would love to read your blog haha.
I make money specifically from knowing how to talk out ideas and implementation with marketing folks these days. It has turned into a specialization of mine by the looks of it, actually. I started doing graphics in marketing as a print designer (might be from that?)
I'm not a technical lead, I'm just a talkative developer/designer and consultant mostly at times. I like to joke and have fun, so that always helps on the getting-to-know on the clients and then understanding their needs.
Lorenzo is correct in terms of us speaking to non techs. Although, I prefer my project managers to be past devs as they understand our pain points more readily on shipping/maintenance/politics, etc.
I still very much need a project manager to check in on me from time and a good manager for guidance on various matters that may crop up. I suppose that would be a form of mentorship in some ways. I have learned a lot from some managers I've had. :)
Thanks for sharing that's really good insight!
Hi Lorenzo,
I signed up here just for this thread. I first would like to thank you for affording your valuable time to answer questions and give back to the development community.
I read in your answers that management is a totally different job to coding, I have series of questions for this:
Thanks in advanced.
Oras
Hi Oras,
Thank you for the kind words. I am glad the discussion is useful, and I it makes all the difference for me to know that I might have been helpful.
Lorenzo, Thank you very much for your reply. Much appreciated.
I was only 10 years old in 84 but I started coding machine code when I was 13. Today I work 2 cleaning jobs that add up to 39 to 66 hours per week that are at night or in the early morning. In theory there should be some part time coding job that pays a lot more but like this my mind is available for personal use.
I'm actually looking to start an internet revolution for the betterment of mankind. (I can dream right?) Over the years I've envisioned some wildly complex ideas that for the most part are well beyond anyones attention span and skill set. (duds) In doing so I started to see that the best ideas are those where a basic understanding can be had in seconds with infinite steps into further complexity.
I've managed to simplify something like a hundred ideas to the point where I should really start working on their implementation. I've picked one for you based on your love for scalability.
The goal is to create a organic new-news aggregation network and to dramatically speed up news aggregation.
It involves 2 file types I called: Even Simpler Syndication [ESS] and No Nonsense Outline [NNO]
I wrote a spec here go-here.nl/ess-and-nno but I think I can give a better description tailored for you.
An ESS is a tiny comma separated text document with a unxi build date, an url for an rss feed then, for each news item, 1) a publication date that is an offset in minutes from the build date and 2) a tiny check sum.
Aggregators should limit their results by age and discard an ESS if its build time or top article indicates it being to old.
An NNO file is the end result of aggregation that can be used for the next session but is primal intend is publication/sharing.
It it s a comma separated text document that starts with a unix build time followed by a sorted list of items 1) feed url, 2) minutes before build, 3) title checksum
The file is build after the aggregator aggregates the users hundreds, thousands or millions of ESS, RSS and/or Atom subscriptions while reducing the result list by a configured amount. (say 3000)
When published a 2nd user can load the NNO into their aggregator which should fetch the top feed items listed in the NNO until they have a screen full of results. (scrolling loads more)
The 2nd aggregator can then proceed to fetch that users own subscriptions and/or parse additional NNO files into the result set.
When done they can publish their own NNO file.
Ideally the aggregators maintain their own manually unsubscribed feed list and implement a configurable filter like a word and a word combination filter, a Bayes filter, a machine learning implementation or some other filters. The news items displayed should have an indication about their origin (which NNO file) and they could provide an auto translate link or do inline-translation of headlines/articles.
The point of the entire exercise is to have people access the internet without a multinational man in the middle.
In my experience a few thousand RSS and Atom feeds will produce at least one truly fascinating thing to read per day while larger amounts allow for more aggressive filtering.
Sadly, RSS and Atom files can be so large and are so hard to parse that a home connection can do only a very limited number of them. If there are a billion websites ten thousand is only 0.001% if each request would take a second to resolve ten thousand would be 166 minutes. If your home pc can do 10 per second you still have to wait for 16 minutes while loading the top 40 results of an NNO file would take only 4 seconds.
I think in those 16 minutes combined with a decade of finding and filtering feeds real value is produced. If the result set can be enriched several times per day with input from other users (thereby allowing for more elaborate contextual filtering) the end result accumulates value faster than it expires.
The big question is: Where do I go from here?
I wrote an (untested) Node.js module for ESS, I will make a PHP version as well. I will attempt to make my powerful but userless aggregator more user friendly but mass adoption is the ultimate pipe dream.
What ideas/suggestions do you have for this project?
Ill add a news result just for fun:
news.go-here.nl
I'm sorry for the lack of tech websites ;)
Your passion for technology is commendable, and your enthusiasm will bring you far. I have a few recommendations:
1) Simplify the message. The important thing is to describe the problem you are trying to resolve and the value your idea will add. If you can't write both combined on one side of a 3"x5" index card, then you should rethink the idea.
2) Conplexity is not a goal. It is the enemy. A path to wildly complex mutation is doomed. The goal should be simplicity.
3) If people can't understand the ideas, it is not a demonstration that the idea is superior than most people. Simplicity is the ultimate good design. The implementation of the idea might be complex, but you need to separate implementation details from the mix.
4) Is the goal to start a business? Or to create technology? This is a key question to know what the next steps are. If you are trying to start a business, then you should get a sense for how you will monetize the idea, put a prototype together and try to raise money or users or both. If the goal is to create technology then you need to implement it, open source it, demonstrate that it works (ship a free product that uses it) and write a detailed technical paper about it. However, technology ideas with no business validation have a very hard time gaining traction.
Hope this helps.
Yes, the question is how to introduce a technology without a business. The only thing I can think of is to get some business to adopt it.
The description here was for you. The "real" description would be something like: Use this module and get subscribers/readers. After all, that is how most use RSS. Implement it and ignore it.
What were your thoughts of going from coding full time to switching to leadership positions? Any reflections on the transition that you'd like to share?
Also, did you ever juggle with doing both at the same time?
The most important thing is that you must be sure that you want to do it. I did it the first time many years ago thinking that it was going to be "business as usual plus some extra management stuff." In reality is a different job, and different focus. It is very difficult to get into a state of coding flow if you are going to be doing coding and management at the same time.
If you want to take the leadership track I recommend to embrace it completely and see how much coding you can fit in your schedule. It will be mostly up to you to decide at that point.
Gotcha, that makes a lot of sense. I'm personally nowhere near taking a leadership role, but I've been thinking about what kind of a career I'd like to have as a developer (and if that includes leadership).
Excellent. Knowing what you want is super important. It allows you to jump into opportunities when they open up.
I'm trying to make it brief, forgive the rudeness :)
You are not being rude at all.
Definitely this. I'm currently making the switch to management and this is one of the primary factors that drove my decision. I feel like I have a lot to offer at the team level (I'm currently a technical lead) but that I'll be able to help even more people in a full-time management role.
Hi Lorenzo, I am quite new to the professional career, I've been working on Enterprise software just for 4 years, before I was just doing small website as a freelancer to pay my university studies.
Something that really scares me is getting old in this job, I can already tell that I am slower to pick up new tech and more attached to what I know in comparison of what I used to be when I was 18-19... and I think this will get worse aging.
I am really scared that at some point I will lose my ability to adapt to changes completly and get useless.
Ho do you keep yourself always updated on cutting-edge tech stack when your learning pace slows down due to the age?
(I am not calling you old, lol, I think is scientifically proven that learning pace decrease with age)
Vincenzo,
Recent studies have demonstrated that the human brain does NOT start to decline past age 25 as we thought it did. It actually keeps on growing! In other words, there is no physiological reason for learning to stop.
What really happens is that we become more resilient to let information in, because new information has to contend with the old stuff we stored.
It's like if our experience makes it harder for new knowledge to stick because new knowledge gets judged and often rejected by the old knowledge. While this is a good mechanism to apply experience to life, it does get in the way in tech.
The trick is to maintain the fundamentals, but question the details you know, and assume that there is always a better way. A better way that somebody probably found, and that you can learn.
The type of fundamentals that you can maintain a bit more closely are things like CS fundamentals, lessons learned personally, things about team work, processes, shipping software, human needs, etc. That stuff is sort of timeless, but it does evolve.
The stuff that is always temporary is stuff like languages, libraries, and frameworks. Those things are like cars. There is always a new model the next year, and it is going to be better than the previous model. Most of the time, at least.
If you look at it that way and assume that everything changes for the better, you won't get stuck in defending old knowledge, and new knowledge will flow into your brain without finding unhealthy resistance.
So... it is all about the attitude toward new things. Fight like hell any temptation to say "this new stuff is junk, in the old days..." It is tempting, but it doesn't work well in tech. Consider anything that exists today as old within 6 months, and keep looking for emerging technologies and trends.
that was a great answer, thanks a lot
My pleasure!!
My advice is to make sure that you create a solid framework, not just a solid language. Ruby would not have been successful without Rails. A solid framework can change the destiny of a language. I am not familiar with Crystal, but I'll take a look.
Any advice for communicating challenges upwards? I'm not interested in becoming a manager, but as a 'senior' person I see a lot of things that are... less than optimal, but framing these challenges(ignoring technical debt in favour of pushing out new features, ignoring 'flaky' tests because we don't have time to investigate and harden the suite, etc) to people without a development background can be difficult, and ultimately, their priorities will override mine.
Yes. To be able to effectively communicate the importance and priority of dealing with technical debt you need to figure out how to quantify the cost of not doing the work and the added value of doing it. In other words, you need to give non-technical decisions makers a way to compare their list of priorities with yours. For example, you could come up with something like: "if we don't fix this issue, we will never be able to scale past X number of requests per day. Given the traffic trends, we'll be there in Y months..."
So... the trick is to convert technical needs into non-technical values.
Hi Lorenzo! Congratulations on your 30yrs! I consider myself an introvert and being in a corporate company, there's a constant pressure to 'build my brand' and to 'go out there and network'. Any advise for introverts like me? :)
Thank you! :) My advice is to read this book. It is a great resource that will help you look at being introvert with different eyes.
The good news is that over time being an introvert will be less and less pronounced. The other good news is that in the tech space, a lot of people are introverts.
I recommend forming strong 1:1 relationships with people that can teach you something, and mentor you. As an introvert, you have the advantage of being good in 1:1 situations, so that will help you a great deal.
How do you deal with underperforming member of a team? What if it's persistent, despite talks, yet it's not big enough to take serious steps (such as firing)? How do you deal with such individuals?
It depends. If they were never strong performers, then I have to let them go. If somebody is consistently underperforming and there doesn't seem to be a path to success, they should find a place where they can be more successful. Allowing mediocrity to linger is a poison for the company and the team.
Otherwise, I start a PIP (Performance Improvement Plan). That is an official, written and well-documented period of time (usually 3 months) in which they have to meet weekly goals and send a weekly report on how they are doing on those goals. During that period it is made clear that if they can't make their goals for X weeks in a row (usually X=2 or 3) then they will be terminated. A PIP is also accompanied with consistent feedback and coaching, both written and oral.
There are 3 things that can happen:
1) The employee understands how serious the problem is, and they do their best to satisfy the PIP requirements. If they succeed, the PIP ends and the employee can stay on board. If they fall back into bad habits, there is no a second PIP.
2) The employee doesn't take it seriously, and nothing changes OR things change for a while, and then they go back to bad. At that point, they are let go exactly as agreed in the terms of the PIP.
3) The employee doesn't accept the PIP, and they are let go immediately. I have never seen this happen.