This content originally appeared on DEV Community and was authored by Vladimir Chuprinskiy
I asked myself that question recently. As Wikipedia states this glorious library is "used by 73% of the 10 million most popular websites. Web analysis indicates that it is the most widely deployed JavaScript library by a large margin, having at least 3 to 4 times more usage than any other JavaScript library".
I came to the short and simple answer pretty fast: I just chose other stacks and projects where jQuery was not required and a person's time and memory are limited. But as I started to reflect deeply on my decisions, I realized that it could be a smart move to write down why I chose this or that language, library, project or position throughout my software engineering path.
Resumes and interviews are very limited. When hiring an engineer, it is essential to understand the person and their experiences, not the most recent skillset. Subsequently there will be fewer misbeliefs leading to losses for both parties. I strongly believe in synergy, so I decided to give a crystal clear description of my software engineering journey for those who might consider hiring me. This retrospective might also be useful for other engineers who contemplate their future careers.
2000. I was not sure whether I was still in The Bubble or not =)
In the beginning of the 2000s automation was thriving. Just about every company or state agency had realized they badly need to store their information in a database and have an application for their employees. I got a job in an enterprise company which executed custom software projects. Initially we crafted 2-tier desktop apps with Oracle and Sybase PowerBuilder. DataWindow saved a lot of effort, PowerScript supported all the 4 OO pillars and had a powerful framework - PowerBuilder Foundation Classes. The ecosystem included PowerDesigner, a database modelling tool I fell in love with. Perfect stack for the problem.
A couple of fellow software engineers next to me were working on a Lotus Notes project. It looked archaic and decaying. In my early 20s I realized that I do not want to get stuck in boring legacy technologies for years.
Lessons learned: Choose wisely the platforms and the languages you’re going to spend your time mastering. Keep an eye on new libraries, software engineers are smart, they create new tools for reasons.
2000. DataWindow example in PowerBuilder 6
The company was not large thus software engineers were universal. Part of my job was communicating with stakeholders and users, collecting requirements and turning them into specs; that was a useful skill. Projects were thoroughly documented so I had to write a lot of docs. I took it as an inevitable evil. Architects were rare, so I had to architect and then code. We didn't have many DBAs, so I had to do most of the job myself. Not having formal CS education, I learned by example and started designing databases in Boyce–Codd normal form without knowing what normal form is.
Lessons learned: Good engineers learn the processes. The knowledge makes them universal problem solvers.
One specific project I remember from around 2000-2001 included manual data processing (no AI back then). The company hired a temporary team of 20 employees and my work was to create an app for them as soon as possible. We forged the first version very fast and then for the next several months I visited their workplace every other day, collected the feedback, watched them use the app and went back to my desk to improve it. It was my early Agile experience. Very few people had heard of the Manifesto back then.
Lessons learned: Short iterations provide more value. Direct user feedback is priceless.
As the company and projects evolved we drifted towards 3-tier desktop solutions. In 2003 PowerBuilder seemed to be stagnant and very niche. Java looked deadly slow on Windows (the Oracle tools I used then were cross-platform written in Java). I had experience with Visual C++ and MFC, but it was not a good choice for fast enterprise development. .NET Framework, the game changer, was rapidly gaining popularity. The supremacy of the tool was obvious to me. I took my part in pushing the company towards its adoption and received Microsoft Certified Solution Developer for .NET in 2004. The company needed certified developers to win the large contracts, I needed to master the framework - a win-win.
Lesson learned: Choose the stack wisely and you will be the most hireable.
I think I owe Anders Hejlsberg part of my success. I used Turbo Pascal at school, Delphi became the bridge to Windows programming. C# was true love. TypeScript - smart way to overcome JavaScript deficiencies.
I wanted to have a bigger impact and figured out the key to more complex projects is teamwork. I decided to take on project management while keeping up with the ever-evolving technologies by coding the core part of each project. Teams were small: 2-5 engineers. Each Project Manager/Tech Lead was given freedom to choose the most convenient methodology. Some of my office mates used RUP. It seemed solid, serious and reasonable. But the first time I tried to start using it for a real project I was swallowed by the whirl of the waste work.
Lessons learned: Books are different from practice. Each methodology might be the best choice for one type of work and a complete disaster for another. I should take care to figure out what problems might arise from each shiny new concept.
I tested a couple of more lightweight and XP methodologies, trying to find the ideal one. Not until around 2005-2006 when I learned of Scrum. I realized all the value it can bring to a team, started using it and have stuck with it since then.
I was eagerly digesting the new knowledge. I realized that web apps are a smarter way to deliver functionality, saving a lot of effort in deployment and maintenance. So I took a deep dive into web development. We fully adopted Microsoft stack: IIS and MS SQL Server. Technologies rushed past: ASP.NET, DCOM, RPC, XML/XSD/XSLT, SOAP and WSDL, WCF and WPF. But the enterprise problems seemed to be the same and in 2008 I got bored. I thought that maybe I should try doing something else rather than programming till the end of time.
Lessons learned: Work without enough challenges is boring. It’s not the tool that makes a difference, but the problem type.
2005. Arkhangelsk. Pretesting C++ DCOM multithreaded server for a 3-way RPC data exchange.
I left the company, stopped coding and started trading futures for the RTS Index. I had savings which meant freedom for me - being able to pause and try interesting things. The financial crisis of 2008-2009 was a great opportunity to learn trading through practice. I had some success, but soon understood that I am inevitably gravitated towards coding. I started automating my trading tools and finished writing a trade bot. I decided that I need communication practice in English, so I took some freelance jobs on oDesk (Upwork) for customers from the USA and South Africa - useful experience. Programmed PocketPC using .NET CF and took other interesting projects. Then I was offered the CTO position.
Lesson learned: I love coding.
The team was small initially: 30 people, 5 or 6 of which were software engineers. The software engineering processes were chaotic. I knew how to rectify that and the rest of the challenges looked fresh. In 6 months I was offered a share of the company and the CEO position. I decided to give it a try. Keeping the role of the Tech Lead, I was in charge of selection and adoption of methodologies and frameworks throughout the organization. I set up the basic processes first: Scrum, git, TDD, CI/CD, Jira and Confluence for task tracking and knowledge sharing. Hired a great QA Lead who could grow a strong QA engineer from any person with a desire to learn.
Lessons learned: CEOs are human beings. Leadership and management can be learned only through practice.
2012. The new team.
The company was private and we didn't have a long credit line. I needed to keep being frugal at the same time building more capable teams in order to take on bigger and more profitable projects. My hiring decisions were money-constrained, so I needed to build a solid team growth process to survive.
Lesson learned: Good process allows a team to share knowledge in a fast and efficient way.
I knew that I must personally do all the hiring: early team members create the stem of a company for years. Wrong hiring decisions can doom any successful team with a great product. So I googled hiring basics and then learned through practice.
Lesson learned: What seems to be the biggest obstacle on your path right now, might become the greatest skill under your belt soon.
Some of the projects required collaboration of multiple functional teams. Each functional team had a strong Team Leader. New projects were complex - a lot of management, so I figured that a matrix organizational structure might be the best fit for the given project types and sizes. I managed to grow the company twice in number, almost all new hires were for the Software Engineering and QA teams. Projects stayed manageable.
Lessons learned: Good project managers are hard to find. The best project managers are good specialists.
We won bigger contracts, but I felt that the company is "bleeding knowledge". The diversity of the projects led to low financial predictability, poor estimates, and, as a result, overwork. So I focused my efforts on a huge project for an electrical distribution company, which, if done properly, could guarantee a big market niche for the company for years to come. We won the project.
Lesson learned: It’s best to do one thing really, really well.
2012. Web GIS for an electrical distribution company.
The company step by step learned to keep the proper pace. We passed the formal ISO 9001:2008 quality management certification, although metrics collection and analysis for process improvements were pretty basic. It was a success, but I was exhausted. I always considered myself a variation of an introvert, but I had to communicate with numerous new people constantly. I do enjoy that, but I need time to recharge - all by myself in the flow.
Lesson learned: I should listen to myself.
After some reflection and googling, I got enlightened that some companies nowadays have engineering tracks. So I felt the urge to switch the position and left in a graceful manner, having mentored the replacement.
Lesson learned: I love coding. There are many different ways to be successful.
In the previous company, I continued to bet on .NET platform - optimal fit for the geospatial problems we solved. We slowly drifted towards mobile and tablet application development through PhoneGap to Xamarin. I had to reconsider the stack. The support and ease the .NET Framework provided came at the cost of being locked in the enterprise world. Most of the new interesting for me companies used other tools. I felt rusty.
Lesson learned: Good tools can become golden handcuffs.
I took the next role for two reasons: it was an interesting engineering challenge and it gave me full freedom in how I reached the results. I could spend my time learning and practicing any technology I wished. The contract constraints dictated a waterfall project structure, though for the software engineering part we used the good old Scrum.
Lesson learned: Gantt charts are still useful.
2017. Intelligent transportation system. Variable message sign installation.
I decided to spend my time mastering the JavaScript stack, as this language was rising in adoption by product companies. I architected an SPA and carefully selected React as the front-end library. Having prior experience with Backbone.js I immediately realized the simplicity and force under the hood. The mobile market was flourishing, and I discovered React Native. I believed it might revolutionize mobile app development, so I rushed to learn it.
Lesson learned: Developers have a gut feeling for good technologies.
It started as a pet project initially, Puncher.app became my path back to full time coding and mastering the right stack, keeping all the best practices from previous iterations. Backend in Node.js, mobile applications in React Native and web frontend in React - all using the same JavaScript language. No need for context switches and double work. I learned containerized deployment with Docker as it seemed the proper way to build scalable architectures and explored the ELK advantages. This set of tools promised to make me a more effective problem solver for the specific problems I was interested in - products used by millions of people. The bootstrapping experience would be a positive side effect. So I made a deep dive in.
Lesson learned: Aim to achieve multiple benefits with a single decision. In the worst case scenario you still achieve something.
React Native, although not without drawbacks of cryptic build errors and raw open source libraries, proved to be the right tool for the job. It has matured now and I consider it the optimal solution for budget-constrained teams, especially those who cannot afford the bus factor of one for any of the critical parts of the project. We made some wrong decisions along the thorny startup path, but they concerned the marketing part and the project scope, not the tools or the processes selection.
Lessons learned: Small startups have to limit the toolbox - this way the team members are universal soldiers. Big companies move away from RN. If you can afford hiring many mobile engineers, it is more reasonable to have two specialized teams for both platforms.
1992. Van Damme movie: Universal Soldier.
Using plain JavaScript instead of more secure TypeScript as the primary development language guaranteed me later the widest selection of junior developers for hire. So I was able to select from the best in no time. They wanted to learn the new hype React library. I wanted to make them more performant as fast as I could. A win-win again.
Lessons learned: Mentoring creates great atmosphere and group dynamics.Although mentees leave, the benefits remain: increased leadership, communication and management skills.
Now, as I feel the need for the next career challenge, I decided to switch to big tech. FAANG-type companies seem to be the most appropriate objective - with the freedom of inter-project migration and great engineering culture to learn from. Particular areas of my interest are those promising the most innovative breakthroughs: Big Data, AI and ML, AR and VR, Social Interactions and Human-Machine Interfaces. Those areas are fenced by extensive domain experience requirements - a chicken-egg problem. I hope to bypass those choosing proper projects within the company. Interesting languages to learn for me are Python for universal adoption in the ML scene and Go for being among the top tools for large scalable services.
Lessons learned: Any software engineer can and should actively manage their own careers through mindful selection of tools and problems they are going to spend their limited time on.
2021. Dockerized services.
PS: If you happen to work in such a company and enjoyed my story, please feel free to contact me: https://www.linkedin.com/in/chuprinskiy/
This content originally appeared on DEV Community and was authored by Vladimir Chuprinskiy
Vladimir Chuprinskiy | Sciencx (2021-12-06T19:21:21+00:00) Why I don’t know jQuery, and I never cared to learn it.. Retrieved from https://www.scien.cx/2021/12/06/why-i-dont-know-jquery-and-i-never-cared-to-learn-it/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.