You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: public/blogs/fundamentals.mdx
+8-50Lines changed: 8 additions & 50 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,32 +6,20 @@ isReleased: true
6
6
isSequel: false
7
7
lastModDate: 2024-04-01T09:15:00-0401
8
8
firstModDate: 2024-04-01T09:15:00-0401
9
-
minutesToRead: 10
9
+
minutesToRead: 4
10
10
tags:
11
11
- 'rants'
12
12
- 'scams'
13
13
- 'skill-issues'
14
14
15
15
---
16
-
17
-
<C>
18
-
This blog post was inspired by a recent conversation with a friend who had completed yet another ripoff JavaScript bootcamp. When they asked me whether they should start with
19
-
<Lhref="https://spring.io/projects/spring-boot">Spring</L>, <Lhref="https://www.djangoproject.com/">Django</L>, or <Lhref="https://expressjs.com/">Express</L>, I got confused. The question seemed misguided, I first thought about redirecting their focus towards a foundational understanding of <Lhref="https://datatracker.ietf.org/doc/html/rfc2616">HTTP</L> and grasp the protocol's essence first. But then I soon realized the broader issue at hand, which is the misconception that learning involves a linear progression of hopping from one tool to another, across different languages and ecosystems.
20
-
<S/>
21
-
It became apparent that my friend's inquiry about different frameworks operating on totally different languages and ecosystems, neither of which they were even proficient in, reflected a common misunderstanding.
22
-
My advice was: focus on learning more fundamentals. Better yet, grasp how computers operate. So I ended up sending them a copy of "The C Programming Language" book and advised them to start there. Reflecting on this, I realized my advice was somewhat selfish, as I didn't want to lecture for 30 minutes about the importance of fundamentals and where to even begin.
23
-
</C>
24
-
25
-
26
-
27
-
<H2>Here's what I should've replied with</H2>
28
16
<C>
29
17
Software development is primarily about problem-solving, just like mathematics.
30
18
</C>
31
19
32
20
33
21
<C>
34
-
In math, attempting to solve complex equations without a solid grasp of fundamental principles by relying solely on memorization, you're trying to piece together a puzzle without a clear understanding of how the pieces fit. Without a foundation to connect concepts, Your brain neurons struggle to connect and make sense of scattered information, leading to frustration, boredom, thus imminent failure.
22
+
In math, attempting to solve complex equations without a solid grasp of fundamental principles by relying solely on memorization, is like trying to piece together a puzzle without understanding of how the pieces fit. Without a foundation to connect concepts, Your brain neurons struggle to connect and make sense of scattered information, leading to frustration, boredom, thus imminent failure.
35
23
</C>
36
24
37
25
<S2/>
@@ -52,10 +40,10 @@ The question is, how do I learn or where do I even look ? The answer is simple:
52
40
Stop falling prey to the false promises peddled by individuals and institutions eager to take your money by selling you unrealistic dreams. Just as you can't expect to achieve six-pack abs and bulging biceps in four weeks with a magical training program advertised by some juiced up guy on Instagram when you haven't stepped in the gym for a day in your life, you shouldn't expect to become a "full-stack" developer in 3 months through bootcamps.
53
41
</C>
54
42
<C>
55
-
So let me say this: Connecting some JavaScript CRUD APIs together does not make you a "full-stack" developer, no one on earth is full stack, you cannot be at all places at once, you cannot be an expert at literally everything at once **ESPECIALLY AFTER 3 MONTHS!**
43
+
Connecting some JavaScript CRUD APIs together does not make you a "full-stack" developer, no one on earth is full stack, you cannot be at all places at once, you cannot be an expert at literally everything at once **ESPECIALLY AFTER 3 MONTHS!**
56
44
</C>
57
45
<C>
58
-
Let me reiterate: connecting some JavaScript CRUD APIs together does not make you a full-stack developer, it only means you've memorized some broken English to create another useless todo app (at least be creative). These advertised programs always **overpromise** and **underdeliver**, setting unrealistic expectations and leaving many aspiring developers disillusioned and frustrated and definitely not ready to deliver in the market, well a marked that is drowning in <Lhref="/blog/tag/skill-issues">mediocre</L> talent anyway.
46
+
It only means you've memorized some broken English to create another useless todo app (at least be creative). These advertised programs always **overpromise** and **underdeliver**, setting unrealistic expectations and leaving many aspiring developers disillusioned and frustrated and definitely not ready to deliver in the market, well a marked that is drowning in <Lhref="/blog/tag/skill-issues">mediocre</L> talent anyway.
59
47
</C>
60
48
61
49
<C>
@@ -78,46 +66,16 @@ Understand that true engineering means going beyond memorization and instead com
78
66
<C>
79
67
When you start asking "why", you'll gradually connect the pieces together, starting from <Lhref="https://youtu.be/SLFN-XfeYXw?si=0IDKskPOzAsI6EIe">bottom</L> and working your way up to abstractions **NOT THE OPPOSITE!** Even creating them yourself. Eventually, you'll have the full picture.
80
68
</C>
81
-
<H2>I Get It, But What Should I learn ?</H2>
82
69
<C>
83
-
I can't precisely outline a <Lhref="https://roadmap.sh">roadmap</L> for you because the field is vast. If I lay out a plan, you might quickly lose interest, feeling overwhelmed by its enormity, you might even focus more on unnecessary topics while leaving more important ones without much attention, because all of these concepts I'll be mentioning will sound like a foreign language to you. Instead, I'll suggest an approach:
84
-
</C>
85
-
<C>
86
-
Just pick a thing, complex or simple, anywhere that you think might be interesting, then keep asking why does this thing exist? What problem is it trying to solve? and follow the trail. By doing so, you'll find yourself going deep into the <Lhref="https://youtu.be/zE7PKRjrid4?si=24T8DoioD-7WotOC&t=93">rabbit hole</L>. It is an intricate journey, but after such a deep dive, you'll find yourself surpassing 99% of individuals out there who don't ask questions and don't even put in any effort at all, just accepting the information as is, and that goes out for everything not just software engineering.
87
-
</C>
88
-
<H2>Here Are Some Tips</H2>
89
-
<C>
90
-
To save you some extra time your journey as a new comer:
91
-
</C>
92
-
<C>
93
-
You can consider leveraging the established paths laid out by reputable educational institutions not <Lhref="/blog/shitty-colleges">shitty ones.</L> Start with the foundational courses, the topics of the Harvard CS major is great way to start. Speedrun through these topics, not all of them, many are just filler courses (universities have to make money too), lookup which ones are which, don't get too deep, you won't use most of them (practically), but they're very valuable to know.
94
-
</C>
95
-
96
-
<C>
97
-
Pick one programming language and stick to it. Don't hop between languages at this stage. Once you have attained proficiency (meaning you can build almost anything with it), explore other languages and paradigms while adhering strictly to their inherent principles and guidelines. It's crucial to refrain from blending different paradigms together, you'll get good at that language once you explore how other languages solve the same problem differently, give each of these paradigms their time. Do not hop too fast between them, also you don't need to master them all, no, just enough to build some quality software with them and attain that **shift in thinking** which is what you're trying to do, not writing 17 different languages in your resume, that only means you're <Lhref="https://www.urbandictionary.com/define.php?term=mid">mid</L> in 17 different languages. Congats! Again.
98
-
</C>
99
-
<C>
100
-
Study code from successful projects like the ones with many starts on GitHub. By analyzing professional code (well, let's suppose it's professional, you won't notice now) written in the languages you're learning, you'll discern patterns, anti-patterns, design principles, best practices and more.
101
-
</C>
102
-
<C>
103
-
Build meaningful and **creative** projects, no trivial "todo" apps, **I swear If I catch someone creating another todo app, it's up!**
104
-
</C>
105
-
<C>
106
-
Draw inspiration from the code you read and aim for projects that challenge and actually engage you, put genuine effort into them. Each project should be unique to maximize your learning, if your brain is not thinking as hard as tough game of chess or poker, you're wasting time and lying to yourself;
70
+
Be an engineer not a <Lhref="https://johndanielraines.medium.com/be-an-engineer-not-a-frameworker-c58fe28d0c88">frameworker</L>, so think like one.
107
71
</C>
108
72
73
+
<H2>I Get It, But What Should I learn ?</H2>
109
74
<C>
110
-
Always consult official documentations and RFCs when learning a new technology, language, or anything in life really. Like the topic of health, read the official studies instead of relying on some guy on social media <Lhref="https://www.urbandictionary.com/define.php?term=Yapping">yapping</L> about "studies show that...". **WHAT STUDIES? LEMME SEE THEM!**
111
-
<S/>
112
-
If the documentation is inadequate, resort to reading the source code and try to connect the dots. Never rely on secondhand information. Your brain may trick you into seeking the easiest path to preserve the most amount of energy, like watching a video or purchasing courses (though the vast majority are a ripoff, some can be time-savers). Distilled secondhand information can lead astray, not even mentioning mis/disinformation.
113
-
<S/>
114
-
Instead, your brain should engage, think, and exert effort to understand, if it's dormant you're slacking big time.
115
-
</C>
116
-
<C>
117
-
Start using Linux instead of you normie operating system, you can search <Lhref="https://duckduckgo.com/?va=i&t=hd&q=man+windows+is+shit&ia=web">why</L>.
75
+
I can't precisely outline a <Lhref="https://roadmap.sh">roadmap</L> for you because the field is vast. If I lay out a plan, you might quickly lose interest, feeling overwhelmed by its enormity, you might even focus more on unnecessary topics while leaving more important ones without much attention, because all of these concepts I'll be mentioning will sound like a foreign language to you. Instead, I'll suggest an approach:
118
76
</C>
119
77
<C>
120
-
Be an engineer not a <Lhref="https://johndanielraines.medium.com/be-an-engineer-not-a-frameworker-c58fe28d0c88">frameworker</L>, so think like one.
78
+
Just pick a thing, complex or simple, anywhere that you think might be interesting, then keep asking why does this thing exist? What problem is it trying to solve? and follow the trail. By doing so, you'll find yourself going deep into the <Lhref="https://youtu.be/zE7PKRjrid4?si=24T8DoioD-7WotOC&t=93">rabbit hole</L>. It is an intricate journey, but after such a deep dive, you'll find yourself surpassing 99% of individuals out there who don't ask questions and don't even put in any effort at all, just accepting the information as is, and that goes out for everything not just software engineering.
Copy file name to clipboardExpand all lines: public/services/glossary.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ A ticket serves as a link between two key individuals: the problem reporter and
46
46
</C>
47
47
<H3id="user-stories">User Stories</H3>
48
48
<C>
49
-
<Lhref="https://www.atlassian.com/agile/project-management/user-stories">User Stories</L> are expressed through <Lhref="https://cucumber.io/docs/gherkin">Gherkin</L> files. These files double as acceptance tests, to ensure a clear understanding while providing a means of verification for the software's functionality.
49
+
<Lhref="https://www.atlassian.com/agile/project-management/user-stories">User Stories</L> are expressed through <Lhref="https://cucumber.io/docs/gherkin">Gherkin</L> files. These files double as acceptance tests, to ensure a clear understanding while providing a means of verification for the software's functionality. Learn <Lhref='/blog/user-stories'>more.</L>
0 commit comments