Ask HN: How does one become a better Software Engineer?

[rxsel]

Assume the individual wishes to build products and the underlying systems atop the web and would strive to be "Fullstack" and dangerous throughout the entire stack.

Feel free to share resources, tips, lessons learned, etc.

[dave_sid]

Hit the gym. The best software engineers I know can bench 60 kilos. Work on your abs and hit the protein shakes. Bill Gates used to do this and look where he is now.

[babygoat]

What is the causal effect?

[robodale]

Build something, from nothing, and make sure it involves a full stack and has users other than yourself...even if it is just one other person. Promise your future self that you will see this through to completion.

Oh, and build something small in scope. You don't want to be working on the pre-launch 10 years from now...

[xupybd]

I would add keep doing it. Iterations build experience. Completion allows you to judge success and refine what works and what doesn't.

[mattbrewsbytes]

Find what interests you in web app development. You mention Fullstack but that really is a recruiter term.

Slowly building a set of problems you have solved is experience. As you encounter similar/same problems, iterating on those solutions makes you a better engineer. Solving those problems with increasing levels of traffic introduces/uncovers new problems to solve across the stack.

Learn from others, co-workers or other companies that publish things about the problems they have solved. Some of the BigTech companies generate frameworks or have services that solve BigTech problems they have encountered. There are solutions there that could be useful. There also are problems + solutions there that no other company is going to run into but people like to emulate so they will use those solutions like a square peg in a round hole.

[ukoms]

Progress not perfection. Which in this context should be read as willingness to getting know new solutions, new technologies and new applications; You delve into things, get some of the ideas, think about them, implement parts of them, fidget with them. BUT! Do not let them overwhelm You. It's virtually impossible for a person who isn't genius engineer to be fluent in all known technologies, languages, libraries and rest of the stuff. You focus on setting in your head memory anchors to different solutions, different approaches, and when the time is done You will end up with bigger knowledge and skill set. You don't need to remember all the details, You just need to remember where to find them.

Second thing - constantly improve communication. Be as humble as You possibly can, because people have their own struggles we are not aware of, and those affect the way they write and speak. That's why You need to remind your self everyday - "is this what I understood really the thing the person has said?". And ask for their understanding of given information. It's basically 70 to 80% work of good SE.

Finally, take care of your physical and mental health. You cannot be productive 24/7. Your body and mind need breaks and maintenance. Treat yourself in this aspect as any other high-grade, professional, top-quality tool. Your mind, your body are your tools - take care of them, so they can perform for life.

Oh! And be nice to yourself. Harsh treating You will most likely get from others. If You don't be kind to yourself, who will be?

[forgotmypw17]

Get some historic perspective. The classic older browsers will run easily in Wine or VirtualBox. Try to build a website for Mosaic. And upgrade it for Netscape 2.0 and IE 3.0. Then upgrade it for Netscape 4 and IE 4, while retaining compatibility. And onwards to today. If you can span 25 years of it, you'll know more than most of today's web devs by a long margin. It is easier than it sounds, especially if you start basic.

[nodelessness]

No. You won't know more than the average web dev by a large margin. You will know very little of what is possible today and some things that are outdated and not relevant any more which are going to be useful in very rare situations.

[forgotmypw17]

Knowing what to do in rare situation is what separates an advanced practitioner from an expert.

[xupybd]

No it doesn't. Knowing how to solve real problems is what makes you an expert.

Who cares if you can make a website with early 90s browsers. That's a skill that is obsolete. It might be fun but it doesn't make you a better engineer.

[ssteel]

It seems kind of obvious, but build the system you are interested in learning how to build. If you want to do it professionally, use common tools. If you want to do it to start your own company, use tools that you are most comfortable in now. Set a goal and once you start walking towards that goal, the path presents itself.

[logicslave]

Work with good engineers, or work with good code bases off github. Theres no way you can conceive of truly amazing software yourself, unless you are linus torvalds. There are patterns, and you need to learn them externally by writing code with others or by working with exceptional open source.

[ioli]

Actually Linus studied the heck out of other codebases. For example, linux itself was inspired by UNIX and it is said that he studied MINIX (minified version of UNIX used for teaching) before he started developing linux.

[i_see_things]

> Theres no way you can conceive of truly amazing software yourself, unless you are linus torvalds

False, in two ways. Truly amazing software do get conceived by an individual. Linux has many flaws.

[logicslave]

Yes it does get written, but if you are asking how to do it, instead of proactively trying, you probably cant do it on your own. 98% of developers cant

[Jugurtha]

This reply will reproduce:

- A reply I wrote to a thread here at https://news.ycombinator.com/item?id=25025253

- A Twitter thread about a few things useful for selling software to companies, discovering patterns, abstracting into a product https://twitter.com/jugurthahadjar/status/131066829330549965...

- Added link: https://news.ycombinator.com/item?id=25288605

<<<

Hi, here are a few things I wrote in here that could be useful. They are designed to improve remembering to do things, doing things, learn from doing things, make sure everyone knows what they should be doing, remember why we're/if we ought to be doing things in the first place, and doing the right things:

- https://news.ycombinator.com/item?id=19924100 (understanding codebases, etc.)

- https://news.ycombinator.com/item?id=22873103 (making the most out of meetings, leveraging your presence)

- https://news.ycombinator.com/item?id=22827841 (product development)

- https://news.ycombinator.com/item?id=20356222 (giving a damn)

- https://news.ycombinator.com/item?id=25008223 (If I disappear, what will happen)

- https://news.ycombinator.com/item?id=24972611 (about consulting and clients, but you can abstract that as "stakeholders", and understanding the problem your "client", who can be your manager, has.)

- https://news.ycombinator.com/item?id=24209518 (on taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable).

- https://news.ycombinator.com/item?id=24503365 (product, architecture, and impact on the team)

- https://news.ycombinator.com/item?id=22860716 (onboarding new hires to a codebase, what if it were you, improve code)

- https://news.ycombinator.com/item?id=22710623 (being efficient learning from video, hacks. Subsequent reply: https://news.ycombinator.com/item?id=22723586)

- https://news.ycombinator.com/item?id=21598632 (communication with the team, and subsequent reply: https://news.ycombinator.com/item?id=21614372)

- https://news.ycombinator.com/item?id=21427886 (template for taking minutes of meetings to dispatch to the team. Notes are in GitHub/GitLab so the team can access them, especially if they haven't attended).

- https://news.ycombinator.com/item?id=24177646 (communication, alignment)

- https://news.ycombinator.com/item?id=21808439 (useful things for the team and product that add leverage)

- https://news.ycombinator.com/item?id=20323660 (more meeting notes. Reply to a person who had trouble talking in corporate meetings)

- https://news.ycombinator.com/item?id=22715971 (management involvement as a spectrum)

>>>

Twitter thread:

0. Form:

0.0. It pays to provide services through a company. Companies write large checks to companies without blinking; not so large for individuals.

1. Contracts:

1.0. Get a lawyer to prepare contracts for collaborations. Someone at some point might disagree or have trouble remembering what they have agreed to pay you, make sure to have a mnemonic device in the form of a clear contract.

1.1. Companies have typical contracts for collaboration: don't sign anything without legal counsel.

1.2. Retain intellectual property to amortize engineering and sell what you make to others.

1.3. Companies might ask that you do not sell to competitors: define them and contain geographic zone and duration. Get paid for the opportunity cost.

1.4. Split project into tranches for which you get paid. This can help cash-flow and reduce risk, especially in the beginning.

2. Presentation:

2.0. Your company solves problems and being open minded about these problems is useful; so it's not much about finding problems for your solutions, but more like finding solutions to clients' problems.

2.0.0 After enough problems you built solutions for, patterns emerge and you can abstract a solution that serves several use cases. See "Abstraction" section.

2.1. General presentation with broad strokes of your capabilities, including previous work with other clients

2.2. Conversation with the prospect on their worries in a given space

2.3. Conversation with the prospect on their worries in a given space

2.4. Extract problems from that conversation and send a list of N problems to solve/ideas to explore.

2.5. The client finds one problem urgent/highest priority/highest value

2.6. You get together and talk about "desirability, fasiblity, viability".

2.7. Once you agree on what to do, prove the concept.

2.7.0. e.g: organizations give us data and ask us to predict something, say customer churn or subway car malfunction. We return predictions, they validate the predictions, and we can then start the project because they have proof we actually can predict what they want us to.

3. Execution:

3.0. Your opinion on what is valuable for the client does not matter. It doesn't have to be valuable to you, only to the client. A client who gets excited by a functionality that took one hour to implement because it solves a real problem is a learning experience.

3.1. Go above and beyond. Some sectors/clients are hard to get in, but once you're in, you're in.

3.2. Listening and assuming the client is smart goes a long, long, long way.

3.3. Send meeting notes to the client. It clears ambiguities during/after the project.

3.4. Press to get the client's domain experts' collaboration. They will actually use what you're building. Get them at the table.

3.5. Some of the most valuable insights are gleaned after a meeting and not necessarily with your "counterpart".

Don't build the wrong thing.

4. Abstract:

4.0. When you solve many problems, some patterns emerge. You built custom products for your clients, but you can abstract functionality and build tooling to scale your services, and enable others to do the same.

4.0.0. e.g: we we built machine learning products for enterprise clients. After many projects, we built iko.ai, our own machine learning platform to "Get Data Products Released".

4.1. One advantage of this approach is to explore the space while being profitable. Some problems exist not for lack of a nice front-end or lack of knowledge of the target audience. Coming at them from a purely "webdev"/"devops" mindset can bring bad surprises.

All the best,

[ironmagma]

Read a wide variety of code. Think of it like reading the literary classics, it gives you a perspective on where we came from and where we’re at. Opening core OSS codebases like GTK and trying to hack on it will get you places.

[giantg2]

Study, practice/opportunity, and drive/passion.