This article explains in easy terms how to be able to contribute to
webpack. The post is not long, but will give you an indication of what
to do to get your contributions submited.
Documentation
Webpack has its own documentation repository and is probably one of
the easiest ways to start on your journey as a webpack maintainer.
Browse through the issues list, look for good contribution labeled
issues or read some of the issues anyway. You can also look in any of
webpacks repositories that isn’t the main documentation repository.
Look for typos, maybe some feature isn’t documented yet. Use your
intuition.
Code
While code i a big part of webpack moving forward, the code also needs
to be documented and new features should be shared with an audience
either through Social Media, or by creating documents internally in
each repository. The best way to get started writing code, is to learn
the exsisting code, setting breakpoints and debugging yourself.
A neat trick, is also to read issues, try to solve those issues
yourself or read up about what people are struggling with.
Community
Being active in the webpack community, writing content and advocating
is fun. You dont need to have a lot of followers, just create good
content and the followers will appear. This could be things like
one-liners that are cool, use cases of webpack and/or other exciting
things you discover one can do with the tool.
Summary
Try contributing to webpack, it will make your profile more attractive
and being involved in a community is super-rewarding. Send me a DM if
there’s anything in this article that doesn’t make sense.
Been in the industry working at multiple companies with different
stages of their development cycle, I’ve been in various of situation
for projects. Either if that is a Proof of Concept, a beta version or
a stable build, it has taught me some tricks and tips that might come
in handy if you are in a similar position. Lets go through these!
Prolouge
Developing a product is not very different than learning to program
for the first time. It takes iterations, sometimes when you encounter
a problem you need to go back and re-deo your implementation as well
as thinking of scenarios where your code will be volatile.
The similarity in the development of a product (in terms of Software
Engineering) is close. In the start of a project you might only need
some requirements to fit your Proof of Concept, while over time you
will need to follow design prinicples, technical specifications or
versioning of your software.
In this post I will chronologically go through how projects evolves
into a state of art products.
Proof of Concept
You might know what a Proof of Concept is, but it’s worth revisiting.
The term denotes a product that is created to show steakholders or
your boss that an implementation works.
Early Stage
In the early stages of a product, you might have created some source
code structure, but it’s far from perfect. Ideally the structure of
the code will make the product itself easy to develop without any
major oversight of process to create a deploy.
In this stage, most of the main features of your product is made,
speed of development is good, but keep in mind that fast development
means more verbose code and messy process of distributing your
software.
Good
Fast development
No oversight
Easy to pivot
Iteration to next phase is easier if features are written first
Bad
Code is messy
No process of development
Intermidate Software
Ideally this is where you want to be as a startup. You have good
source structure, code style is followed, formatting and some
documentation of how to run the repository is given.
In a startup environment this is where you want to be. In the union of
stable software with strict, well written and documented code and a
fast phased development.
Good
Structure while maintaining speed
Easy to create functionality
Simple to onboard
Creates good value w.r.t time used on bringing value
Bad
Hard to onboard sometimes
Lacking technical specifications
PM/Dev might write bad issues, hard to reproduce issues
Stable Product
In stable products your CI/CD for development, staging and production
is good. Like mentioned in the last section this is where you have
good abstractions of code, well documented code, documentation is
top-notch and your source code is very specific. Ideal in a situation
where your product and features doesnt change much (but at the cost of
slow churn!).
Good
Structure in every part of project
Good reproduction cases
Split responsibility of code
Tehcnical speicfication always guuaranteed
Bad
Hard to onboard sometimes
Not easy to pivot
Features takes more time
Conclusion
All of the stages a project is in depends of the requirements and
vision of your product. Personally, being in the middle of a stable
product and an intermediate solution creates more value while having
good enough boundaries for a developer to make good code.
Del Mozarella ost og legg de jevnt utover hele pizzabunnen.
Topp med Basillikum og chasewnøtter.
Stek på 225C i midten av ovnen i 20 minutter.
Du kan eventuelt bruke Jalapenos for et ekstra “kick” i smaken.
Fordel Pesto over hver bit etter steketid, eventuelt rømmedressing,
Siracha, majones eller rømme.
Computer Science is so vast, yet limited. We’ve discovered so much,
but how far away are we from other disciplines? Not far. By looking at
biology, chemistry, math (of course) and languages, we can abstract
more or less anything into these concepts and interchange these topics
with one and another.
An ecosystem
In Biology, we use ecosystems to denote a set of animals that live
together and the use of animal resources to construct a cycle of life
and death. Birds eat fish and fish eat alges. Alges consume oxygen and
sunlight. How can we relate this to Computer Science? It is no hard
task. If we think of the ecosystem of the whole machinery of
programming, with CPU’s,
ALU’s and registers. We can then relate fish as
instruction code, and birds as programming langugages. If we can make up large
programs based on how we fly, we can learn to fly by really well. We
can travel large distances, meaning we can construct a lot of
programming langugages.
Programming languages are the best way to reason about the computer,
because we tell how the computer should behave, rather than how it
should behave in detail. A fish and a bird are the same, namely
animals. Animals behave similar. If we can write machine code, we can
write a programming language. Assembly and JavaScript could generate
the same code, but a fish use less time to fetch food than a bird that
need to evaluate everything in its eyesight first.
Programming languages and machine code tells how code is structured,
and how it should be exceuted, just as animals. Let’s go in depth of a
use case of how we can relate.
Everytime a human needs to move, it sends signals to it’s brain.
Similarly, everytime we need to retrieve something from a server, we
send a
SYN/ACK
in a TCP protocol. The SYN in this example, is the brainwave
requesting access to the hand, and the ACK is the movement of the
hand. How can we use this? Imagine you need to construct a data
structure. We can say that we are reading a book. Ironically the first
pages is a dictionary of how the book is constructed. For this
exercise, let’s make a double
Linked List. First, the book is connected by pages and the book as a whole.
The previous page is the Linked Lists’ previous pointer, the next is
the next page and the page itself is the data the node holds. Easy,
right?
So far, we’ve considered ecosystems to be dependent on each other, but
they are also encapsulated. One could say that a tree and water are
dependent on each other, but the tree is also dependent on itself. It
needs pollen to flourish, and it needs to be located with safe ground
to become a healthy tree. We are encapsulating data in the tree. The
leaves we are getting, are not only the information the tree holds,
but also a reference to the tree, meaning it’s inheriting the DNA of
the tree. Trees also have this kind of inherance on a higher level,
meaning classes of trees is a set of trees that act on behalf of each
other. Trees
communicate with each other. They tell whenever a danger is nearby, and they can behave as a
flock, disrupting air.
When we want to transfer information in the brain, we use neurons, or
even blood. Blood transfers data too, food! Food is essential for us
to function, we carry medicine and vitamins in the blood.
bird eating plastic
In the ecosystem, we can relate to a buffer as the ecosystem parts
transfering
toxic substances
to its lower chain in the energy pyramid. A bird can transfer its
digested plastic, to a fish, and we will fish that, and then we will
consume that plastic. All the way, a buffer made that possible,
us!
We use all our vocabulary to denote Computer Science expressions, and
perhaps my favorite one, is debugging. Whenever it is a bug in our
code, we need to debug it. Same goes for humans, whenever we need to
figure out what is wrong with us, we go see a doctor. The doctor is
the programmer, and the bug is us. We search for answers, then we
apply those answers to a solution or a fix. These fixes often needs to
be maintained, just as you need yearly checkups at a dentist, you need
to check your program every now and then. The only difference, is the
time span.
To conclude this, you clearly can draw parallel lines between Software
Engineering and other genres. From Medicine to Biology, we can
construct the same meaning to different problem sets.
Navigating the webpack landscape is often hard. You don’t know what to
put in your configuration or how it should be done. With webpack UI, I
hope to make it easier for people to create or manage their webpack
configurations.
Brief Introduction
Webpack UI is a scaffolding website made to make it easier for people
to create or manage their configurations. With the UI, you are able to
modify existing configurations, create new ones or choose templates
that will generate best practise configurations for you. This project
needs sponsoring though. If you want to support me, consider donating
here
When working with source code, either if it is Open Source, Closed
Source or as a collaborative effort, one thing is inevitable;
PRs.
Pull Requests are the final stage of getting your code ready for
a production build, staging or to any sort of project where other
people will rely on the code you write. It is important that it
lives up to the expectations of the codebase. In this post, I will
try to summarize some things I have learnt through Open Source and
working together in teams for companies.
A review in progress
Submitting Unfinished Code, Drafting and PR Discussions
I really like how the
Lighthouse
team at Google handles their Open Source projects, and it is no lie
that I have been inspired by how they govern their projects. They are
good at what they do and they have experience. For instance, instead
of bringing up long discussions of an issue through the issue tracker,
a collaborator sometimes submit a draft PR with a rough sketch of how
things would work, and then they have that discussion at a code-review
level instead.
Some might argue that this is bad, although in my opinion, it is
easier to understand the practical case if you have some code to refer
to. Submitting unfinished code is not a bad thing, not following up on
your work is. What that means, is that if you submit a draft Pull
Request, it is easier for people to follow your thought process and
intention as why they should implement a potential feature or bugfix.
Code is a common thing for all developers, and people can make their
own conclusions based on that. By the way, GitHub now has a nice
drafting
feature that I really like, which makes it easier for maintainers and
for developers in general to have these kinds of discussions. The only
downside I can come up with submitting a draft Pull Request (as a way
to discuss a potential fix or implementation), is that time is lost if
not accepted. Now, why would you care and why would you need to do
this?
What Your Team Wants x What Your Team Needs
Working in teams consists of some sort of splitting of roles,
traditionally you got some sort of leader, either if it is a tech
lead, product manager or senior developer, it is important that you
have someone to guide and provide balance to a team of engineers (and
or designers). I will use these terms interchangeably. This individual
should be able to be a bridge between the product and technical needs
of a project. That is sometimes is hard to balance.
To do this, for instance, a
Product Manager
should be able to understand what the product needs, by talking to the
right people, and by being a good messenger to the developers (and or
engineers, designers) implementing. This is like Yin and Yang: If the
Product Manager fails at one side, the other will suffer. You can be
good at figuring out what your product needs, but bad at messaging
that to the developers, which then would have downsides. It is
important to balance the equation in such way that both the product
will see daylight, as well as that it is delivered by the engineers
and designers. This is usually why large scale companies split a
Product Manager Role between a more product sided role and a techncial
one (and maybe you should do too).
Let me go through some Point of Views from different roles under a PM,
for us to better understand why communicating in Pull Request Reviews
are important.
Designer
As a designer I need to know a lot about a product in order to
implement it, it is important for me to understand what the need of
the product is, what a user is struggling with and what features we
need. This way, I can more precisely put together a design and
solution to a problem space. I need some users feedback in order to
know why the design I have sketched out is bad, in
order to know how to fix those.
Engineer
As an engineer, I need to know the requirements of the product, a use
case or an elaborative description of the problem, in such way that I
know how to implement it. I do not need designs for this initially,
but I will need them in order to convey a understanding of the
technical requirements if there are no technical documents. I need to
understand why we need this feature or fix in order
to understand how to implement it.
What it means
As briefly shown, these two types of roles are dependent on a Product
Manager delivering information to them, one being user feedback, the
other being a technical requirement or document. A routined leader is
therefore needed, in order for teams to stay on a positive trajectory.
Both of the tasks mentioned, needs some sort of recipe, much like
composing a dinner that consists of different components together. In
order to cook the entire dish (your product), you need to do well in
both making the main component (i.e meat) as well as the siders
(salad).
This is where the Pull Requests come into play. As both designers,
product managers and engineers (designers should have GitHub too, we
can fight about it online) needs to communicate, the last step of the
train ride is usually the written code. It is easier to iterate on
code, than it is to plan first and then write. You will remove a chain
of dependency because most teams are agile in some way.
If you have a good CI, you have a test server your designer could
give feedback based upon, which makes things nice.
Externalizing tools
As designers nowadays use Figma, developers use GitHub and Product
Managers use Jira, you will loose some speed versus quality and
deliverables. I would say that you need to be able to access the
content quickly, either by having a dedicated README for where to find
critical information at your main documentation source, or have it
pasted in red, capitalized letters at your doorstep for quick
accessability. Clarity is the important part. If you live in three
distinct worlds, loss of effectiveness as a result of communication
being spread across tools is more likely than speaking two different
languages. Write good issues, elaborate precisely and listen to
feedback.
For Agile teams, in specific, I cannot say this enough:
"write good issue tickets".toUpperCase(); it
will reduce your time to implement drastically because you do not need
to browse through a lot of information to implement something or step
into the Product Manager role.
In Code Reviews, technical talk wins, i.e “The button does not show
when hovering” versus “I cannot press this button, is my internet not
working?”, as it vague and does not convey action or constructiveness
towards a fix.
Design talk (altough it is good to discuss in Pull Requests) are what
issues are for. Higher level (non-technical) issues and a mix between
abstractions, the correct way to implement and technical flavors are
intended for Pull Requests.
If you do not have an agile team, you will usually have a QA tester
that will make case studies to reproduce, screenshots and their
versions in jira or at the Pull Request itself (a good behaviour to
mimic). Note here that feedback comes in form of what works versus
what is not working, not how it looks.
A final point, is that discussing and fixing constraints in PRs make
the steps to production less cumbersome and the likeliness for
finishing a feature is bigger, as the code is being continously
validated and pushed towards either staging or production. Speed and
Value.
Techniques For Improving Reviews
Altough review quality might differ in terms of experience, there are
a few tricks that makes the process easier.
For starters, if you notice code conventions differ, it might be a
good idea to point that out. If you notice a user bug, point that out.
Anything that might affect the issue will help triaging. Be
constructive, no need to be rude, HOWEVER be proffessional such that
the review is taken seriously and that the author will follow up on
actionable items. Constructiveness is important, because it is easy to
come of as arrogant as a reviewer, and when tables turn, you are the
one that will suffer from that (karma or something).
Constructiveness and indicating progress is important.
Some Pull Requests are big, take those reviews in stages. Do not
review all files at once, pick a few and if there are issues (with the
code reviewed), comment those. This will make the process easier. Look
at PRs like a fluent set of waves that work together to hit the
shoreline. You are not alone, split the review across the organization
and team, reviews are not a one man show.
These are important, but how do you know how to actually review?
I have
some methods to determine which type of review to do.
Simple Reviews and Small Source
If the code is small, and you know that the user experience is not
affected, looking at the code is enough. The quality of the review
usually is based on the experience of the reviewer, but keep in mind
to comment on inconsistencies and ask for an explaination where
needed.
Intermediate Reviews and Architectural Changes
Once a Pull Request grows in size, the importance of making a good
review increases proportionally. Have a look at the structure is it
written. Is it following good practise? Is it concise with rest of the
codebase? If not, indicate you want those aligned. For features,
testing is important, but for a developer, this is above your
paygrade. QA, PM, Product Owners or similar will test the usability of
the software. If not, split this responsibility with someone else. The
author should not review this him/herself because the
ones that usually makes a change is blind to the bugs a merge might
introduce. However, the author might know pitfalls, so ask for those
edge cases. If there is some edge cases that might not be covered,
optionally split those into issues so that you are aware of a
potential issue (or fix it in review).
These intermediate reviews differ. For instance, if the source code is
good, but the architectural structure is bad, you will need to maybe
put up a figure, do a pair review to figure out a good solution to the
complexity it introduces. If the architecture is good, code is bad,
you will need to test the request locally and verify that the code
compiles and behaves as usual.
Intermediate Reviews and Large Source Changes
Big source code is hard to review, because it introduces more concepts
for a developer to get. Even though knowing an entire source is not
required, it is important to understand what
this Pull Request would do. For those kinds of
reviews, a one-on-one, asking the author to go through the source
might be positive, or multiple reviews with multiple developers, that
is up for you to decide.
Advanced Reviews and Architectural Changes and Large Source Changes
I have encountered these kinds of Pull Requests and these normally
comes from a refactor or a big feature being introduced. If it is a
MVP and your team is agile, merging an unfinished PR to staging might
be good, but if this is meant for production, make sure to be accurate
in your reviews. This means that you need to figure out if the
abstractions are good, if the source code is consistent and complies
to your standards. Pick one of two things to focus on: Architecture or
Source. Usually I begin with the abstractions and architecture, due
the fact that it is easier to fix code standards rather than
abstractions once the Proof of Concept or Intent to Implement
(Permission to implement this feature is ok) is approved, thereby
spending time better.
Verification and Roles within Teams
As mentioned, it is important to split tasks, because a Pull Request
is a fluent process. Multiple people are involved to shape a product
in the long term. Sometimes the source needs a massage, sometimes
content needs verification from marketing and sometimes testers need
to figure out if the code fixes the issue. All these tasks are why
people have fancy titles. These tasks should be split across a
longitude of people and if you do not have those roles, figure out
something with your co-engineers.
If you have a Product Manager, this is your point of contact. The
Product Manager is a Steve Jobs for Software, and a Product Manager
not making sure the product is on-line is not good. Developers should
code, Managers should manage, that is how it is. Developers have
blindspots that managers pick up, so it is important to convey those
facts during testing, such that the feedback loop is tight.
Summary
In this post I have explained how I would consider a good Pull Request
process to be like in teams and people working together. Make sure
that your code is consistent, split responsibility, pick your type of
review and iterate towards a fix.
You can hit me up on
twitter
for questions or feedback on this post.
Are manual Performance Optimizations sufficient enough?
For the last year, I’ve focused on tooling in order for front-end
developers to keep their focus on building rich user experiences that
isn’t abounded by lack of toolchain knowledge. I began developing
mink, a string template -based scaffolding tool for universal react
applications with
webpack. A lack of tooling to give beginners an advantage over a sea of
information and anti-patterns inspired me to bring up the
discussion
of an extensive, yet simple CLI tool for both scaffolding and running
a rather complicated bundler, webpack.
The problem about initial user confusion and hardship isn’t singular
to webpack. Most of the choices a developer makes during an average
work day is, by my experience proportional to;
Integration & re-iteration.
These two categories are pretty simple to understand, yet they are
very hard to keep separate. As a “Junior Developer”, I’ve
often found myself re-writing code based on feedback a lot, which
basically is defined as re-iteration. In fact, I used 2–3 months on
the
webpack-cli
to figure out how to write a scaffolding tool that is efficient and
extensive.
Performance is just that.
This is a bold statement, but nobody cares about performance
in the integration phase, especially not beginners. You’ll have to
iterate a couple of times, maybe even finish your application before
you start being selective about how the user interacts with your app
with respect to performance. This has implications, because
nobody finishes their app, unless there are a lot of people
working on it.
Google has done an incredible job promoting good practises for the
web, which makes it easier to approach performance in a constructive
way.
Lighthouse
is in my eyes, one of the most valuable repositories today as it gives
developers an insight about how well their application is doing and
suggestions to fix performance issues or relative. As a toolsmith, I
wish that we could one step further, by not only suggesting, but
rather implementing those suggestions,**
so that a developer doesn’t have tospend time on re-iteration** too much.
It makes more sense to use time implementing core functionality and
let toolchains fix human-errors.
Data-based tooling
In tooling, I’m excited about automation of work that could ease
not only for beginners, but also established developer’s tasks.
We’ve got CI’s, code formatters, CLI tools for scaffolding and
performance hints, but no tool yet for predictive data loading or
automatic fixes to source code based on data and performance
hints.
Data-based tools are important, because the data already gives us an
indication of how well your application is doing either by how big
your source code is, when you decide to load the code, your first
meaningful paint or when your application is interactive.
There’s several tools that already gives us these metrics, such as
lighthouse audits, monitoring network requests and service worker
activity in chrome and the output of module bundlers on compilation.
How it is realistically possible
After getting data from
chrome protocol, module bundlers,
react-tracking
or lighthouse, one’s got a lot of information to use with machine
learning. The optimization itself could potentially be done on runtime
with
worker-threads or clusters, along with editing the source code with AST’s.
For automatically improving applications based on lighthouse audits,
one doesn’t necessarily need machine learning optimizations, some
changes could be done just with the use of AST’s.
Our goal is to make libraries easier to use, but 0CJS is not about
running one magic command to fix every issue a potential user of your
library has, it is much more than that.
There are many aspects of succeeding in creating a well written CLI
tool, I’m not going to go through all of those aspects, just three;
Baselines, Abstractions and Zero Configuration.
Baselines
When describing baseline, what I mean is that your tool should have a
good foundation to succeed. This is the goal of your tool, how you
approach the problem and how you choose to implement it. For instance,
what makes sense to hide from the user, and what is useful? This could
be something as primitive as hiding status text, or outputting
information about what your tool is doing while the user awaits for
compilation to finish.
The more time you think about how the tool behaves, the less time you
have to spend on fixing bugs and refactoring your code, because you
are thinking about the user and what they might struggle with.
A technique to help you, not bound to Agile Development, Test Driven
Development or any other fancy term, are design schemes. With
webpack-cli, we decided to use
Test Driven Development, but we did also decide to write design documents to save us work in
the future. We knew how the architecture would look like before hand,
implementation and abstractions became easier.
If you think about what your tool might look like in a couple of
months, you saved yourself some months answering issues with your
project. Have a clear goal in mind.
An example of how architecture can play a huge role in the long term,
I’d like to use
Polymer-CLI
as an example.
Polymer
is entirely class based and runs commands with a runner. The source
code is slim, intuitive and it is friendly for new users with its
commands; init, analyze and serve.
Abstractions are leveraged in a variety of. You’re probably using one
right now. Abstractions are key design pattern in CLI tools.
Abstractions are superb, as they hide complexity from the user. You
abstract modules, the tool itself or any other type of system, such as
Google Chrome doesn’t require you to know how
v8
works.
As a library author, one essential thing all users want to do, is to
customize. The solution you’re providing isn’t always optimal for
their use case, and they want to customize your tool to fit into their
integrations. This is where ecosystems comes in hand. Ecosystems could
be denoted as another level of abstraction, except it is based on the
tool itself. One example of this is
yeoman.
As a library author, you could create scaffolding instances of your
tool where yeoman abstracts the details from you. Yeoman takes care of
prompting users for questions and preparing folder structure. The only
thing yeoman should be concerned about, is using those inputs with
your framework or library.
Ecosystems serve as a way to abstract complexity, either by asking
human-friendly questions, or by abstracting your core logic into a
more convenient API. That’s a good thing.
Babel
has succeeded in this by allowing people to write plugins for their
tool.
NPM
has succeeded in this by allowing everyone to use a library with a
single install command.
There are nuances of how ecosystems function, but they have one
thing in common, they hide complexity.
0Configuration.js
When you as a library author have the responsibility of promoting good
practice, you should be aware of the defaults you are setting. Imagine
millions of people using your tool. Take
React
or
Vue as
two examples. If React doesn’t set good defaults to users, then no
user would. As the library author, follow advice from advocates,
Microsoft or Google.
It’s important to underline the importance of promoting good practices
and not anti-patterns, because when you as an author dont know how to
set good defaults, why should the user?
One tip I learnt from being involved with webpack-cli is that you
don’t necessarily have to be in line with what everyone says, as long
as you’re setting a default. For instance, if you have a configuration
based project, which needs an entry point of a users’ application
(webpack), why can’t you set the entry point to
src/index.js instead by default? Users will follow that
pattern eventually. By setting conventions and listening to advocates,
you’re already well off.
Google Developers is a good resource when educating new users
Google Developers is a good resource when educating new
users
Another point worth mentioning is to scale complexity. The initial
user might need a lot of help getting started, so asking users to fill
out long lines of code to get the application booted up and ready
might not be ideal. Instead, scale up complexity. The more users use
your tool, the more creative you could be with options and allowing
users to set those. Performance isn’t always one sided, users have
different ways of rendering their application. Rather than fine-tuning
that in the start, let users gradually do so.
As you might have got a hint of, is that 0CJS isn’t only about letting
the user run your app straight away, it’s about educating them. 0CJS
shouldn’t be an excuse not to know the tool, but rather a way to use
the tool without knowing how it works early in the project.
Educating the developer is important, because if we do so, they know
how to fix potential memory leaks, bugs or issues they might have. For
instance, imagine a user using the
webpack-offline-plugin
without knowing what it is. Without knowing
service-workers, users can use them. This is all about hiding the complexity from
the user, so that he or she doesn’t have to implement a whole
service-worker.
However, we do want to educate people on service-workers, why they are
important and how they work. If the user then have an issue, they
don’t have to refer themselves to
Stack Overflow
all the time, they might have the background information and knowledge
of how a service worker functions to know what the issue is.
Finally, I want to wrap this up by mentioning
Create React App
and how it makes such a great tool. Create React App sets defaults, it
has user guides longer than an academic paper and allows people to
dive into React without knowing any build step. That is where we want
to be, when people don’t have to know tools before actually using the
library. In the end the user might need to know about the tool, but it
isn’t initially important.
This is what scaling complexity looks like in practice. By allowing
people to eject, they allow people to work with complexity, but by
default, the user doesn’t know anything about the underlying logic.
CRA also educates the user, which makes it easier to onboard new
people into the front end realm.
This summer I was an intern at
Cognite, a firm that is trying to make digitalize the industrial world. It
was great and I have had a great time! I will try to summarize my two
months into this post.
I was employed as a Software Engineer Intern and I worked on a lot of
exciting stuff, both in front-end but also alot with cloud functions,
backend and some front end infrastructure. It was great and I really
liked the ability to switch between tasks, as long as the context
switching would not be too big. As an intern, we had a onboarding
period where we learnt more about how the company was like, how to
navigate around and other practical stuff.
They also hosted social events, all sorts of! Everything from soccer
on fridays, to kayaking together. This kind of culture is something I
have not experienced before and in the start I was really shocked that
this was how working in tech should be, and they were entirely right
about providing the most supportive and kind environment for me to
explore and be in. If someone from Cognite reads this, that was really
important to me personally.
As a SWE intern, I was handed tasks given to regular Engineers and I
was super happy for having the challenge of a regular employee. That
is the only way you grow. When I reached out to my manager asking to
work on a collaboration with NASA Goddard, in order for Cognite to use
the timeseries data they have to improve our solutions, my manager was
really positive. For me, having that freedom means a lot, because you
learn yourself and you provide value for others as well as the firm
itself, a “win-win” situation.
In general, Cognite is flexible and is an understandable, inclusive
employer (and I am not getting paid to write these words). By that,
they understand that an employee is effective some parts of the day
and some other not so. What that meant, was that they understood that
you needed to take a step back to be more productive, and that social
life as well as personal health was important to them in order for
them to make me succeed, which I think was one an eye-opener for me as
well.
This is what tech companies should be like and I was lucky to have a
chance there working alongside some mega smart (and driven!!) people.
If you consider to work in Norway, already working here or want to
work for an employer that actually cares, I would consider Cognite.
All in all, a successful internship, getting new friends, producing
code and having fun. Thanks to everyone being apart of that, much
appreciated. If you have questions about how it was there, feel free
to reach out to me and I will be happy to provide some thoughts!
