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 tec...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Hi,
If you are asked to step up is because you probably display traits of a good leader naturally. That is great.
My advice is to embrace the leadership role and truly understand what it means before it is announced and made official. You want to make sure to truly grasp what leadership is, and how that changes your job. I recommend reading everything you can put your hands on about leadership. Take it as you would take a new technology. Become a student of leadership. Be humble, study, find a good mentor, and take the journey as a change in career path, not just "something more you are asked to do." It is a very important path.
Hey Lorenzo,
it looks like you have good experience on Scrum as well...
Can you talk on responsibilities of a PO vs team/technical lead ?
Background is, that i feel my current team setup is far from reaching its potential.
A while back i was driving a lot of things for a new project... i liked it, most important it felt like flow. E.g. the ticket ordering felt like 'Yeah, thats the good next step', thing were building on each other.., etc..
Since PM/PO slowly took over most of the ticketing, planning workflow i'm now at a point the flow experience is most of the times lost, sense of priorities is decreased, meetings are boring and it feels like 'Yeah i can work for the next two weeks or take PTO, doesn't really matter for the company'.
Now i'm almost too tired to work on better responsibility structuring, but i would like to get your input on this!
I feel a little bit like 'Please care about the high level things you want to have, talk to customer's etc.. convey everything to me and/or the team and let us figure out the rest. Also in prior teams i sometimes had the impression the team lead is suggesting every step to the PO so that the PO can repeat it and make things official that way... which feels like wasted time...
So, did you use Scrum before when you were driving the projects? Or is Scrum something that was introduced recently?
I like to have 3 persons. A Scrum Master, a Product Owner, and a Project Lead.
The Scrum Master deals with the process. They schedule meetings, keep the teams on track during the meetings, remove impediments, drive plannings, demos, retrospectives, etc.
The Product Owner is the business owner of the project. They are able to answer questions or go find answers to the questions.
The Project Lead is a technical leader, who understands the details of the project.
I wrote some notes on this model in an article on my company's tech blog. You can find it here ; take a look, and let me know what you think and/or if I can clarify it. I wrote this a long while ago, but I think it is still valid and I have had very good luck with it.
In general, I recommend bringing problems related to the process at the retrospective, and not hold any punches. That is what retrospectives are for. Scrum is very flexible, and if the people involved understand it, you can change it to satisfy your team's needs.
I've been in software field last 10 years. So many challenges I've found so far. Every day is a learning day. Hats off to you, You spent 30 years of coding and that too full time. Salute you buddy!!
Thank you!!! Challenges keep on coming. It never gets boring :)
Yes! The biggest advice I can give is: Be flexible!
Let your team refine the process and don't use any process blindly without adapting it to the situation. I have seen Scrum work beautifully, and terribly as described in any of the books out there. The part that many people forget to pay attention to the fact that processes are frameworks, and can and must be adapted to work with the situation.
When I started I should have been networking more with others. I worked very hard on many things that nobody knew about. I should have been reaching out to put my name out there. At the time it was difficult without the Internet, but not impossible.
If I had a time machine I would go back and network and partner with other people.
Since taking on a management/leadership position, what's the most valuable skill that you've had to cultivate/learn?
People skills. In particular:
Do you have a framework you abide by when providing feedback? i.e. SBI feedback, feedback sandwiches, etc.
Hey Jess,
It is so dependent on the person that a single framework doesn't do in my experience. Some people need feedback in one way, while others need it in another way. For example, the feedback sandwich idea is good in most cases when the feedback has some mildly negative connotations and the person I am talking to is sensitive and receptive. In case of someone who tends to not hear the negative, it is too subtle and needs to end on a stronger note.
Hey Lorenzo,
I've found that some people and devs need more squishy feedback... and some less so. I'm the type that needs "squishy" feedback. This could be just me though and it sounds similar to what you've said here?
Other techs/devs/people would want the how to fix without the cushion as much.
I usually go for a little bit of squishy if I don't know the person. I try to go for respect mostly and try to notice or feel vibes (if that makes sense).
Hi, did you feel to quite profession in your career?
OR Are you feel that much of energetic when you have joined career?
I never considered quitting my career. I am a software builder and I cannot imagine doing anything else at this point. Things might change later on, but for now engineering is where my passion is.
That said, my career is evolving. I started very low level and moved more and more high-level overtime.
Thanks for reply, your last sentence is amazing. "I started very low level and moved more and more high-level overtime." I think this will make you more passionate.
English is the only human language that really matters in software development, IMO. It is a lingua franca.
Any advice to newbies on applying for jobs and what to expect during interview process? What should we expect in terms of culture adaptation from student to actual developer?
A few things to consider (some similar to a previous answer I gave):
1) Network, network, network. Linked is your friend. 80% of jobs in tech are found via networking, and many never get published.
2) Bring 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) 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.
4) 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.
5) Life as a developer is much different than the life as a student, but it depends on the size of the company. The bigger the company, the more people with specific roles and responsibilities you'll have around. A strong mentor will help you with the transition from student life to development life.
6) For the interview, expect to be grilled at the whiteboard. That's what happens in most cases. Do not resist that process, even if it is uncomfortable. Try to look at it as a fun thing. It can be, and it is almost unavoidable.
7) YOU CAN DO THIS.
Thank you so much for the information.
Another thing, as someone with management and leadership experience, when you bring on new/jr. Devs is there anything that you need them to absolutely know or a deal breaker for candidates?
For junior devs I look for passion and for willingness and ability to learn. I also look for exposure to at least two programming languages and solid problem solving skills.
What advice would you give to someone who, besides programming, wants to manage/leaderize the developer team he/she works with?
And where could I learn about all that leadership stuff, btw?
Management and leadership are very different things. To manage you need to be put in charge by the organization. To be promoted to a management role you need to figure out from your boss what it would take to get there.
Leadership is much different and much more important than management. Leadership is not a title. It is a behavior.
To lead you must gain the respect of the team. Leading people is only possible when the people allow you to do so.
I recommend starting by reading everything you can about leadership. Not just leadership in tech, but leadership in general. Here are a few books that I recommend to start:
Also, you need to find a mentor. Somebody who you believe is a great leader, that is willing to teach mentor you.
Hope this helps.
I'm a young PM, and I've already gotten scrum and studied the PMBOK. What other skills/knowledge can I pick up to better serve the devs & product? Should I just start learning out stack?
The more technical knowledge you have, the better you can be as a PM. That said, it all depends on the type of teams you are working with, mostly so that you can follow the nuances of the discussions.
I'd recommend focusing on soft skills before you focus on technical skills. You can add much more value as a great people person than a somewhat technical PM. Becoming "technical" as a PM will take a long time before it brings value, but focusing on people skills will make you stronger much faster.
Got it! I use "Monaco", but I am not too particular.
Well if it's not overly rude I did just post this question maybe you could give your input here?
community.operationcode.org/t/what...
To me, the most important skills a developer needs to have are:
1) Practicing the craft with the intent to learn, and not with the sole intent to get something to work.
2) Always thinking about abstractions for every concept. If the customer says "2" you should think "a number". If the customer says "I need this to look pretty", you should think "let's parameterize everything that could make something pretty".
3) Love for technology.
4) Collaboration, collaboration, and more collaboration. The time for a lone developer changing the world is passed.
5) Ability to estimate the cost of solutions. Most developers I've seen having a hard time simply had no idea how long it would take them to resolve a problem. It is difficult, but if you work on it you get better overtime.
For a Developer having experience of 5+ Years, communication skills play considerable role. How do I improve my them??
The best thing you can do is to show what you can do and show passion for the work. Also, make sure to give a good impression with the engineers you work with. If they praise your work, things get much easier.
I always recommend having the discussion about potential future possibilities before accepting the internship. If it already started, just bring it up once you feel like you have gained the respect of the team.
In preparation for the discussion, make sure to have a good plan for what you want to do and why you'd like to stay with the company. Knowing what you want and being able to describe it is half of the battle.
Thank you!