Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "networking is important"
-
We had a Commodore64. My dad used to be an electrical engineer and had programs on it for calculations, but sometimes I was allowed to play games on it.
When my mother passed away (late 80s, I was 7), I closed up completely. I didn't speak, locked myself into my room, skipped school to read in the library. My dad was a lovely caring man, but he was suffering from a mental disease, so he couldn't really handle the situation either.
A few weeks after the funeral, on my birthday, the C64 was set up in my bedroom, with the "programmers reference guide" on my desk. I stayed up late every night to read it and try the examples, thought about those programs while in school. I memorized the addresses of the sound and sprite buffers, learnt how programs were managed in memory and stored on the casette.
I worked on my own games, got lost in the stories I was writing, mostly scifi/fantasy RPGs. I bought 2764 eproms and soldered custom cartridges so I could store my finished work safely.
When I was 12 my dad disappeared, was found, and hospitalized with lost memory. I slipped through the cracks of child protection, felt responsible to take care of the house and pay the bills. After a year I got picked up and placed in foster care in a strict Christian family who disallowed the use of computers.
I ran away when I was 13, rented a student apartment using my orphanage checks (about €800/m), got a bunch of new and recycled computers on which I installed Debian, and learnt many new programming languages (C/C++, Haskell, JS, PHP, etc). My apartment mates joked about the 12 CRT monitors in my room, but I loved playing around with experimental networking setups. I tried to keep a low profile and attended high school, often faking my dad's signatures.
After a little over a year I was picked up by child protection again. My dad was living on his own again, partly recovered, and in front of a judge he agreed to be provisory legal guardian, despite his condition. I was ruled to be legally an adult at the age of 15, and got to keep living in the student flat (nation-wide foster parent shortage played a role).
OK, so this sounds like a sobstory. It isn't. I fondly remember my mom, my dad is doing pretty well, enjoying his old age together with an nice woman in some communal landhouse place.
I had a bit of a downturn from age 18-22 or so, lots of drugs and partying. Maybe I just needed to do that. I never finished any school (not even high school), but managed to build a relatively good career. My mom was a biochemist and left me a lot of books, and I started out as lab analyst for a pharma company, later went into phytogenetics, then aerospace (QA/NDT), and later back to pure programming again.
Computers helped me through a tough childhood.
They awakened a passion for creative writing, for math, for science as a whole. I'm a bit messed up, a bit of a survivalist, but currently quite happy and content with my life.
I try to keep reminding people around me, especially those who have just become parents, that you might feel like your kids need a perfect childhood, worrying about social development, dragging them to soccer matches and expensive schools...
But the most important part is to just love them, even if (or especially when) life is harsh and imperfect. Show them you love them with small gestures, and give their dreams the chance to flourish using any of the little resources you have available.22 -
I'm drunk and I'll probably regret this, but here's a drunken rank of things I've learned as an engineer for the past 10 years.
The best way I've advanced my career is by changing companies.
Technology stacks don't really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it's not going to be the same as webdev or embedded. But all fields have about 10-20 core principles and the tech stack is just trying to make those things easier, so don't fret overit.
There's a reason why people recommend job hunting. If I'm unsatisfied at a job, it's probably time to move on.
I've made some good, lifelong friends at companies I've worked with. I don't need to make that a requirement of every place I work. I've been perfectly happy working at places where I didn't form friendships with my coworkers and I've been unhappy at places where I made some great friends.
I've learned to be honest with my manager. Not too honest, but honest enough where I can be authentic at work. What's the worse that can happen? He fire me? I'll just pick up a new job in 2 weeks.
If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.
pour another glass
Qualities of a good manager share a lot of qualities of a good engineer.
When I first started, I was enamored with technology and programming and computer science. I'm over it.
Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.
The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
Related to above, writing good proposals for changes is a great skill.
Almost every holy war out there (vim vs emacs, mac vs linux, whatever) doesn't matter... except one. See below.
The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me.
If I ever find myself thinking I'm the smartest person in the room, it's time to leave.
I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.
We should hire more interns, they're awesome. Those energetic little fucks with their ideas. Even better when they can question or criticize something. I love interns.
sip
Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.
Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.
The greatest programming language ever is lisp. I should learn lisp.
For beginners, the most lucrative programming language to learn is SQL. Fuck all other languages. If you know SQL and nothing else, you can make bank. Payroll specialtist? Maybe 50k. Payroll specialist who knows SQL? 90k. Average joe with organizational skills at big corp? $40k. Average joe with organization skills AND sql? Call yourself a PM and earn $150k.
Tests are important but TDD is a damn cult.
Cushy government jobs are not what they are cracked up to be, at least for early to mid-career engineers. Sure, $120k + bennies + pension sound great, but you'll be selling your soul to work on esoteric proprietary technology. Much respect to government workers but seriously there's a reason why the median age for engineers at those places is 50+. Advice does not apply to government contractors.
Third party recruiters are leeches. However, if you find a good one, seriously develop a good relationship with them. They can help bootstrap your career. How do you know if you have a good one? If they've been a third party recruiter for more than 3 years, they're probably bad. The good ones typically become recruiters are large companies.
Options are worthless or can make you a millionaire. They're probably worthless unless the headcount of engineering is more than 100. Then maybe they are worth something within this decade.
Work from home is the tits. But lack of whiteboarding sucks.37 -
Still trying to get good.
The requirements are forever shifting, and so do the applied paradigms.
I think the first layer is learning about each paradigm.
You learn 5-10 languages/technologies, get a feeling for procedural/functional/OOP programming. You mess around with some electronics engineering, write a bit of assembly. You write an ugly GTK program, an Android todo app, check how OpenGL works. You learn about relational models, about graph databases, time series storage and key value caches. You learn about networking and protocols. You void the warranty of all the devices in your house at some point. You develop preferences for languages and systems. For certain periods of time, you even become an insufferable fanboy who claims that all databases should be replaced by MongoDB, or all applications should be written in C# -- no exceptions in your mind are possible, because you found the Perfect Thing. Temporarily.
Eventually, you get to the second layer: Instead of being a champion for a single cause, you start to see patterns of applicability.
You might have grown to prefer serverless microservice architectures driven by pub/sub event busses, but realize that some MVC framework is probably more suitable for a 5-employee company. You realize that development is not just about picking the best language and best architecture -- It's about pros and cons for every situation. You start to value consistency over hard rules. You realize that even respected books about computer science can sometimes contain lies -- or represent solutions which are only applicable to "spherical cows in a vacuum".
Then you get to the third layer: Which is about orchestrating migrations between paradigms without creating a bigger mess.
Your company started with a tiny MVC webshop written in PHP. There are now 300 employees and a few million lines of code, the framework more often gets in the way than it helps, the database is terribly strained. Big rewrite? Gradual refactor? Introduce new languages within the company or stick with what people know? Educate people about paradigms which might be more suitable, but which will feel unfamiliar? What leads to a better product, someone who is experienced with PHP, or someone just learning to use Typescript?
All that theoretical knowledge about superior paradigms won't help you now -- No clean slates! You have to build a skyscraper city to replace a swamp village while keeping the economy running, together with builders who have no clue what concrete even looks like. You might think "I'll throw my superior engineering against this, no harm done if it doesn't stick", but 9 out of 10 times that will just end in a mix of concrete rubble, corpses and mud.
I think I'm somewhere between 2 and 3.
I think I have most of the important knowledge about a wide array of languages, technologies and architectures.
I think I know how to come to a conclusion about what to use in which scenario -- most of the time.
But dealing with a giant legacy mess, transforming things into something better, without creating an ugly amalgamation of old and new systems blended together into an even bigger abomination? Nah, I don't think I'm fully there yet.8 -
Friend: Networking is important. My boyfriend introduced me to X, who then introduced me to Y and that's how I got a job.
Later that day...
Friend: Why didn't you apply for this party? What did I say about networking?
Me: Because I didn't know and because I don't follow that guy on twitter so I didn't see he tweet the google forms.
In my mind: How come nobody introduces me to anybody?
I was just mad that this happened and had to get this out of my head. Nobody ever introduces me to anybody and I am really really shy and an introvert, so I almost never introduce myself to anybody. Clearly I'm gonna die homeless or have a shitty job. Hey artists, I'll gladly take that fucking exposure!10 -
TL;DR Dear boss, firstly, you always get someone to review anything important done by a fucking intern.
Secondly, you do not give access to your fucking client's production server to an intern.
Thirdly, you don't ask your fucking intern to test the intern's work that has not been reviewed by anyone directly on your client's fucking production server.
Last week, the boss and one of the lead devs (the only guy with some serious knowledge about systems and networking) decided to give me (an intern who barely has any work experience) the task of fixing or finding an alternate solution to allowing their support team access to their client machines. Currently they used a reverse SSH tunnel and an intermediary VH but for some reason, that was very unreliable in terms of availability. I suggested using OpenVPN and explained how it would work. Seemed to be a far better idea and they accepted. After several days of working through documentations and guides and everything, I figured out how OpenVPN works and managed to deploy a TEST server and successfully test remote access using two VMs. On seeing my tests, the boss told me that he wanted to test it on the client network. I agreed. Today he comes to me and he tells me to prepare testing for tomorrow and that the client technician is going to give me access to one of their boxes. And then he adds, "It's a working prod server. We'll see if we can make it work on that" and left. I gaped at him for a while and asked another dev guy in the room if what I heard was right. He confirmed. Turns out, the lead dev and the boss's son (who also works here) had had a huge argument since morning on the same issue and finally the dev guy had washed it off his hands and declared that if anything goes wrong from testing it on production, it's entirely the boss's own fault. That's when the boss stepped in and approached me. I ran back to his office and began to explain why prod servers don't top the list of things you can fuck around with. But he simply silenced me saying, "What can go wrong?" and added, "You shouldn't stay still. You should keep moving". Okay, like firstly what the fuck and secondly, what the fuck?.
Even though OpenVPN client is not the scariest thing to install, tomorrow's going to be fun.4 -
Storytime!
(I just posted this in a shorter form as a comment but wanted to write it as a post too)
TL;DR, smarts are important, but so is how you work.
My first 'real' job was a lucky break in the .com era working tech support. This was pretty high end / professional / well respected and really well paid work.
I've never been a super fast learner, I was HORRIBLE in school. I was not a good student until I was ~40 (and then I loved it, but no longer have the time :( )
At work I really felt like so many folks around me did a better job / knew more than me. And straight up I know that was true. I was competent, but I was not the best by far.
However .... when things got ugly, I got assigned to the big cases. Particularly when I transferred to a group that dealt with some fancy smancy networking equipment.
The reason I was assigned? Engineering (another department) asked I be assigned. Even when it would take me a while to pickup the case and catch up on what was going on, they wanted the super smart tech support guys off the case, and me on it.
At first this was a bit perplexing as this engineering team were some ultra smart guys, custom chip designers, great education, and guys you could almost see were running a mental simulation of the chip as you described what you observed on the network...
What was also amusing was how ego-less these guys seemed to be (I don't pretend to know if they really were). I knew for a fact that recruiting teams tried to recruit some of these guys for years from other companies before they'd jump ship from one company to the next ... and yet when I met them in person it was like some random meeting on the street (there's a whole other story there that I wish I understood more about Indian Americans (many of them) and American engineers treat status / behave).
I eventually figured out that the reason I was assigned / requested was simple:
1. Support management couldn't refuse, in fact several valley managers very much didn't like me / did not want to give me those cases .... but nobody could refuse the almighty ASIC engineers. No joke, ASIC engineers requests were all but handed down on stone tablets and smote any idols you might have.
2. The engineers trusted me. It was that simple.
They liked to read my notes before going into a meeting / high pressure conference call. I could tell from talking to them on the phone (I was remote) if their mental model was seizing up, or if they just wanted more data, and we could have quick and effective conversations before meetings ;)
I always qualified my answers. If I didn't know I said so (this was HUGE) and I would go find out. In fact my notes often included a list of unknowns (I knew they'd ask), and a list of questions I had sent to / pending for the customer.
The super smart tech support guys, they had egos, didn't want to say they didn't know, and they'd send eng down the rabbit hole. Truth be told most of what the smarter than me tech support guy's knew was memorization. I don't want to sound like I'm knocking that because for the most part memorization would quickly solve a good chunk of tech support calls for sure... no question those guys solved problems. I wish I was able to memorize like those guys.
But memorization did NOT help anyone solve off the wall bugs, sort of emergent behavior, recognize patterns (network traffic and bugs all have patterns / smells). Memorization also wouldn't lead you to the right path to finding ANYTHING new / new methods to find things that you don't anticipate.
In fact relying on memorization like some support folks did meant that they often assumed that if bit 1 was on... they couldn't imagine what would happen if that didn't work, even if they saw a problem where ... bro obviously bit 1 is on but that thing ain't happening, that means A, B, C.
Being careful, asking questions, making lists of what you know / don't know, iterating LOGICALLY (for the love of god change one thing at a time). That's how you solved big problems I found.
Sometimes your skills aren't super smarts, super flashy code, sometimes, knowing every method off the top of your head, sometimes you can excel just being more careful, thinking different.4 -
I'm too young to have taken my last job...
Enough with the jokes. I have been networking with a lot of people through the years of working at companies and that paid off.
When people trust you for your knowledge, then it's normal to attract business offers. Also, you can partner up with people. That's how my last job started and is still going. At a previous company, I interviewed a guy who had the skills and motive to replace me, but he didn't get the job cause my boss was stupid (he was lucky not to work there, for real).
After I left, he called me to offer me a partnership. One year later and we are killing it, became good friends too.rant partnerships even friendships out of nowhere stupid bosses everywhere networking is important wk77 -
Learning programming, networking, robotics, and other technical skills are very important but do not forget that these are future working software developers.
They will need to know a lot more intangibles. Like effective pair programming, performing proper git pull requests and code reviews, estimating work, and general problem-solving skills and more.
These people will be learning technical skills for the rest of their life (if they are smart about it) but what can really get them ahead is the ability to have good foundational skills and then build the technical skills around them over time.